I want to set an opensource project where users can be sure that the deployed version .heroku.com corresponds with the actual source code in github master branch github.com/
Is there any way to prove a heroku deployment corresponds to a github repo?
Your app can spit out the latest deployed Git SHA if it has the "Dyno Metadata" feature turned on: https://devcenter.heroku.com/articles/dyno-metadata
Using that, you can show the latest SHA and compare it against the public repo.
Also, to add to what Jon said, you can do this via the heroku releases command. Every release, be it a code deployment, config var is 'tagged' - the command will show you everything that has changed on your app and a deploy will show the short git SHA, you can copy the SHA and then use the git command to search the repo for it.
eg.
assuming heroku releases returns
v10 Deploy 33f21247 foo#bah.com 2018/09/03 10:01:38 +0100
then you could do:
git cat-file commit 33f21247
which will then output the corresponding match, or a message saying it's not found. Obviously, this assumes your local repo is in sync with GitHub. To check it against GitHub you'd need to open your repo on GitHub like:
https://github.com/heroku/{projectname}/commit/{sha}
which will show the same commit on GitHub.
Related
I have several Visual Studio solutions that have both a local repository and one on GitHub. I've already made many changes and successfully pushed those changes to GitHub.
But now Visual Studio has forgotten that one of my local repositories is associated with a GitHub repository and I can't seem to figure out how to reconnect it. In fact, it no longer lists that repository in my list of GitHub repositories.
In the image below, you can see I have a local repository called Toxic, but that repository does not appear in the list of GitHub repositories. If I try publishing the Toxic project to GitHub, it just tells me the repository already exists.
How the heck can I get all of my existing Github repositories to show up in the top section shown above so I can push my latest changes?
it appears the only option is to clone the GitHub repository locally, copy my modified files over the newly created repository, and then check in my changes.
Try fist:
installing Git for Windows (command-line)
cloning your remote repo in a new folder
adding your existing repository as a remote
fetching and see if you can cherry-pick your commits
That is:
git clone https://github.com/<user>/<repo> newFolder
cd newFolder
git remote add old ../path/to/old/local/repo
git fetch old
git log old/master
git cherry-pick old-sha1..old/master
(with old-sha1 being the first commit you want back)
Then add the newFolder in your Visual Studio workspace, and see if everything works (do a modification, add, commit and push)
Unless I'm missing something, it appears the only option is to clone the GitHub repository locally, copy my modified files over the newly created repository, and then check in my changes.
Of course, I lose all my comments and iterations since the last check in to GitHub. And care had to be taken not to delete the .git folder, and to copy over all changed file and delete any that had been removed. Seems like there should be an easier way but this certainly did the trick.
I'm no git expert, but I think I might be able to help, if I'm not too late.
Run:
git remote -v
This should print something in the form of:
origin <remote_repo_url> (fetch)
origin <remote_repo_url> (push)
If you only see:
origin (fetch)
origin (push)
try running:
git remote set-url origin <remote_repo_url>
If you get no output then run:
git remote add origin <remote_repo_url>
And then try
git push -u origin
The -u or --set-upstream flag will set origin as the default repo for your branches.
I want to build a project in Azure Pipelines, but I want to know what the idiomatic way is to obtain the latest tag, latest tag distance, and repo remote path/URL in order to pass those values into the actual build script that is inside the repository.
Previously our build script would invoke hg log -r . --template with a clever template, but we found when moving to Continua CI build server that the build agent doesn't have access to the actual repository during a build, and had to find another way.
I'm assuming the same issue would crop up with Azure Pipelines and haven't quite found the relevant docs yet on artifact versioning.
Many thanks in advance.
For git at least, Azure Pipelines does a full clone of the repo by default, unless you explicitly denote that you're doing a shallow clone (source: https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops).
Deriving the version/tag can be done via normal git commands (i.e. git describe --tags or whatever you prefer), which can then be saved as VSO variables to be accessed in later steps in the same job (see https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#set-variables-using-expressions for more info on how to do that).
I'm using Golang and GitLab CI, and I've got a GitLab CI configuration which works perfectly for 12 projects, but not for a 13th.
The problem I have is that I'm trying to go get some private repositories, which go get tries to run over HTTPS, which is turned off.
The solution, that works in the other repos, is this:
git config --global url."git#gitlab.my.site:".insteadOf "https://gitlab.my.site/"
However, in the runner for this one project, on the same GitLab, with the exact same config (except for the service name), this happens:
[...]
$ git config --global url."git#gitlab.my.site:".insteadOf "https://gitlab.my.site/"
$ cd ${APP_PATH}
$ go get
# cd .; git clone https://gitlab.my.site/group/project.git /go/src/gitlab.my.site/group/project
Cloning into '/go/src/gitlab.my.site/group/projects'...
GitLab: The project you were looking for could not be found.
fatal: Could not read from remote repository.
Why is it suddenly trying to clone over HTTPS? It happens in this one project only, consistently, but works in all the other ones. The only reason I can think about is that this one project uses a lot of different repos, rather than just one or two, but I have a hard time seing that this would be the actual issue.
How can I troubleshoot this?
Thanks.
Found the answer, and it's silly, and of course, my fault. I hadn't added the deploy key to the projects, of course rejecting the clones.
To fix the problem, in GitLab, go to the repository and then "Settings" > "Repository" and fold out "Deploy keys". There, make sure that the key you're trying to clone with is available and enabled.
Since travis-ci.org doesn't support bitbucket.org I need another CI service which supports it and allows managing the build commands in a VCS file (like .travis.yml in travis).
My quite annoying research result so far is:
semaphoreci.com: projects which are forks aren't listed even after refreshing the project list
app.shippable.com: signing up with both github.com and bitbucket.org doesn't work
codeship.com: doesn't support to run commands as ''root'' user((https://codeship.com/documentation/faq/root-level-access/))
www.snap-ci.com: no support for bitbucket.org((http://www.slant.co/topics/186/~hosted-continuous-integration-services))
I don't get why people would not want to share the CI service build commands in the VCS - chances of good collaboration without such a feature seems small to me. Even if one adds a script file in the VCS it still needs to be set up in the CI service which appears to be an unnecessary step.
A few months ago Bitbucket launched Pipelines. Quoting from the link:
Continuous delivery is now seamlessly integrated into your Bitbucket Cloud repositories.
You may use it on free plans, but next year they will reduce the build minutes for free plans from 500 minutes to 50 minutes as told in this link.
Also, CircleCI is supporting Bitbucket. It has free plan with 1500 build minutes. It can be triggered by commit or tag in BB. https://circleci.com/
The company that owns BitBucket also has a product called Bamboo for CI. Though most should work with any git that provides a webhook.
According to this blog, it is possible to use Travis-CI for Bitbucket:
Clone github repository:
git clone https://github.com/{github_user}/{github_repository}
cd {github_repository}
Add submodule bitbucket repository:
git submodule add https://bitbucket.org/{bitbucket_user}/{bitbucket_repository}
Add .travis.yml to root dir:
git:
submodules:
false
before_install:
- echo -e "machine bitbucket.org\n login $BITBUCKET_USER_NAME\n password $BITBUCKET_USER_PASSWORD" >~/.netrc
- git submodule update --init --recursive
$BITBUCKET_USER_NAME is bitbucket username
$BITBUCKET_USER_PASSWORD is app password
Open https://travis-ci.org/{github_user}/{github_repository}
A Semaphore CI user can add a fork of a project to his Semaphore account following these steps on the documentation page. Also, Semaphore is building a fork pull request and those builds are visible.
There also is (now) an option to use GitLab as CI/CD server for repository hosted on Bitbucket.
See the documentation here: on GitLab site
I know that a git push origin master will let Openshift redeploy the application to its new version.
But my situation is that my Tomcat application depends on another sub-module maven project, and they are both snapshot.
Once its sub-module project changes (the Tomcat application remains the same), the git push origin master doesn't work at all (Everything up-to-date) and of course Openshift will not redeploy my application, which means that it doesn't renew the newest sub-module snapshot artifact for me.
So, how to solve this problem? I have tried rhc restart and rhc reload, but they doesn't work. Is there some command like rhc redeploy?
You can run
rhc app deploy HEAD -a <appname>
if you're using the command line tools
You can start the deploy steps by ssh'ing to your openshift application. Check your ssh line from https://openshift.redhat.com/app/console/applications/ -> Click your application and then "Want to log in to your application?". Check https://www.openshift.com/developers/remote-access for detailed help (thanks RustyTheBoyRobot).
Once in, run:
gear deploy
Are you sure that you've pulled and committed the most recent changes to the submodule? What's probably happening is the reference to the desired submodule commit isn't updated, so even though the submodule has changed, you project doesn't really know about it. I believe git submodule status should show you the commit your main project currently knows about.
To update this reference, follow these directions.
[main]$ cd ./subm
[subm]$ git pull origin/master # or fetch then merge
[subm]$ cd ..
[main]$ git commit ./subm -m "Updated submodule reference"
If you actually committed changes in the last step, then OpenShift should update it appropriately (since this time, there were changes to the git repo).