So I originally named my github repo my_repo, but then renamed it my-repo shortly after creation, like within the first day. This was roughly a year ago.
Ever since, I've been building the project with Travis CI, using the free .org version. Now after making all my repos private and upgrading to the pro version with travis-ci.com, I've had to provide new API credentials in my .travis.yml. So I have to do so with
travis encrypt $(heroku auth:token) --add deploy.api_key --pro
This has worked with other repositories, but not this particular one. Instead, I get
repository not known to https://api.travis-ci.com/: dben89x/my_repo
However, on my Travis CI dashboard, it's trying to build it as dben89x/my-repo. I'm not sure how to tell travis to build it as dben89x/my-repo.
All my git remotes are set up as my-repo. I've tried logging out in the CLI and logging back in.
I found the answer here: https://github.com/travis-ci/travis-ci/issues/3264#issuecomment-180246348
Went into .git/config and changed
[travis]
slug = dben89x/my_repo
to
[travis]
slug = dben89x/my-repo
Related
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 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.
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).