Imagine situation like this on github:
repo 1
repo 2 (has dependency to repo 1 build artifact)
where both of these have travis configured.
However I'd like to run travis build of the repo 2 also in the case of successful travis build on the repo 1.
Any chance/idea how to achieve that?
The only idea I had was to:
create new user
and in case of successful travis build of repo 1 do git commit + push repo 2.
However that would lead to dirty commit history on repo 2. Well I could also remove all the new user's old commits, but that increases the complexity might be error prone.
Sorry, It's not possible to do that right now, as you can only start a travis-ci build on a commit at the moment.
Obviously not ideal, but you can, however, in repo 2, clone git repo 1, run the repo 1 unit tests in repo 2, and if they fail stop the repo 2 unit tests from running and end the build.
Unfortunately Travis CI doesn't provide this feature. There is feature request for it, but wasn't approved yet, so it's not even on roadmap so far.
This is reason why I switched to similar service: drone.io.
It's relatively new so some languages are in beta so far. Don't know if it is option for you.
It provides more features than Travis CI,
One of them is HTTPS hook for remote triggering the builds.
So you can configure repo1 Drone job to hit build hook of repo2.
This can be done via wget command (You need to wrap repo2 hook URL into double quotes).
Related
I'm working with Cake and Teamcity and I'm trying to access which branch a GitHub PR is targeting
Been trying to find a GitHub API wrapper for Cake do to the job, or a plugin/script to TeamCity to populate some parameter with the value, but no luck so far.
Is there any good wrapper for Github PR in Cake or TeamCity that i have missed?
I'm certain there is nothing that you have missed.
The question would be - before searching for how to do this in Cake - how to obtain the information in the first place.
If you were building on GitHub Actions, there is the github.base_ref which GitHub populates for PRs and which would contain exactly what you are looking for.
Now, I don't know how TeamCity does the checkout so I can probably not really help you. What I can do is give you a pointer:
What AppVeyor does when building a PR is this:
git clone -q <url of repo>
cd <name-of-repo>
git fetch -q origin +refs/pull/<gh-id-of-pr>/merge:
git checkout -qf FETCH_HEAD
If you - in that state - do
git branch --contains HEAD^1
the output (at least in my tests) is:
* (HEAD detached at FETCH_HEAD)
develop
As said above, I am not sure what TC does for a PR build but I guess you'd need something along the above lines.
I, personally, would try to get the required information using git commands before checking what the GitHub API can do.
In the end I found and used the Octokit SDK for dotnet
https://github.com/octokit/octokit.net
As I for #Nils answer would also need the authorization for the repo to run the GIT commands, i went with a higher level solution more native to Cake
We seem to have an issue merging pull requests which are from forks like here and here. Creating pull request from branches is totally fine and is being triggered by travis ci. Is there some settings which needs to be set for the travis CI? See the travis file here. Thanks.
Answer from travis team:
The checks on the links are branch builds. For them to work, the PR author needs to set up Travis integration for their repo, too, with travis-ci.com, and run a build for the tip of the PR branch. It is this build that the PR UI is “waiting for the status to be reported” of.
The check that would run in your repo is the PR build. It runs on a “merge preview” commit that Github autogenerates for PRs.
The types of the checks to run you configure in branch protection settings at Github.
I have a weird issue. Travis OSX builds keep failing because a Jasmine unit test doesn't pass. But, this ONLY happens for commits against the main GitHub repo's master branch. Forked repos, PR's on the main repo, etc do not have this issue. Here are a couple of scenarios:
I sync local master from upstream master and push. Travis build fails.
I make a change, literally any change such as adding a random character to readme.md, commit and push, and the build passes.
I open a PR, the PR build passes
The PR is merged to upstream master, the build fails
There are no issues when running the unit tests locally, so I can only pin it as a GitHub and/or Travis issue. Tried clearing the caches in Travis and did not help. I scrolled through the raw logs side-by-side from a failed and passing build and they were fairly identical, at least nothing I wouldn't expect to be different.
So kind of at a loss here on what to do. Any suggestions?
https://github.com/Glavin001/atom-beautify/blob/master/.travis.yml
This was not an issue specifically with the master branch.
The issue was caused by the Travis environment variable, TRAVIS_COMMIT_MESSAGE. When you merge a PR on GitHub, the default commit message has a "message" and a "description", separate by a line break. Having that line break in the TRAVIS_COMMIT_MESSAGE caused path issues with Ruby and/or Rubygems.
This was resolved by blanking out the environment variable by adding the below to our .travis.yml in the before_install step at the very beginning:
- export TRAVIS_COMMIT_MESSAGE=""
How is it possible that Travis the build failed for the latest push but passed the Pull Request?
On this Gist, you could find the failed and passed output log of the npm run build command that Travis gives. You could also find the configuration of Travis and here below:
install:
- npm install
- npm install -g angular-cli
language: node_js
script:
- gulp html
- gulp scss
- gulp ts
- gulp node
- npm run build
node_js:
- "6.9"
cache:
directories:
- node_modules
- bower_components
Background
This repository is configured in Travis CI to run tests on two environments - named pr and push.
A Pull Request (pr) build will be named continuous-integration/travis-ci/pr and from the docs:
Rather than test the commits that have been pushed to the branch the pull request is from, we test the merge between the origin and the upstream branch. To only build on push events, you can disable Build on Pull Requests from your repository settings.
A push build will be named continuous-integration/travis-ci/push and from the docs
Travis only runs a build on the commits you push AFTER adding the repository to Travis.
Solution
Since the merge of your branch into the base branch passed tests for continuous-integration/travis-ci/push, updating your branch to include the latest commits from the base branch will get your branch passing tests. From the image above, the GitHub UI should allow you to Update branch from the Pull Request page.
Caveat
With branch protections in place, it should be unlikely that your branch fails tests while merging into the base branch succeeds.
Be sure that you confirm that whatever was broken was actually fixed. That is, did someone "fix the build" by disabling that failing test in the base branch? As a cautious person, I would cherry-pick fixes into your branch to verify the problem is resolved.
By a comment of #osowskit, I've found the solution of the problem. He/she said:
PR will merge your changes into the base branch and run CI tests. Push will run CI tests on the current branch. Merging the base branch into your branch will likely resolve your build test on the branch.
We are using a private GitHub Organization as version control. When a task is assigned to a developer, they fork the primary repository, make their code changes, and submit a pull request to have the changes merged into the master branch of the primary repository.
We are also using TeamCity for CI. It is currently configured to kick off a build for a VCS commit, which builds, tests, and deploys the artifact to an artifact repository internally. To accomplish this, the Team City build configuration has multiple VCS roots installed; one for the primary and 1 for each developer's fork.
The problem is that Team City pulls from all of them when a commit is made assuming they are all necessary for the build instead of allowing you to only pull from the single repository that triggered the build. Any thoughts on how we can accomplish this without having to create n build configurations in Team City for each project (where n == number of developers working on a project)?
I see way to do this with preserving current workflow is turning off automatic checkout (VCS Checkout Mode), and checking out code manually in an additional command-line build step, with a parameter %teamcity.build.branch% (logical branch name).
I.e.:
git clone ...
git checkout %teamcity.build.branch%
Triggers will just start the job if there are changes in developer's VCS root, fulfill branch env variable; no automatic checkout will happen and then build step will check out only needed branch. Only works with one git URL.
After posting in the JetBrains forums, I was pointed to a blog that answers my question.
TL;DR: my approach of using feature branches does not work with GitHub's workflow. Instead, Forks and Pull Requests should be used. The blog referenced shows how you can use Team City to trigger off of a Pull Request. Simply add +:refs/pull/*/head to "Branch Specification" in your VCS Root and all pull requests to the Source repository will trigger your Build Configuration.