I am pushing a PR on a project, and the build fails.
I know that the master branch works.
How do I tell circleCI to build all the commits in-between so that I see which change broke?
This isn't currently possible. If you push one commit at a time, CircleCI will build each one. If you push multiple commits at once though, it will only build the head commit.
We do have a feature request open for this, which can "heart" to add your support: https://discuss.circleci.com/t/manually-trigger-a-build-all-commits-between-two-revisions/10160
Ricardo N Feliciano
Developer Evangelist, CircleCI
Related
I just set up Travis CI and I noticed that every time I push a branch to the remote repo, it kicks off a build. From my reading of the docs, this is not expected behavior...it should instead only kick off builds when a pull request is opened and on subsequent pushes to that branch.
Also, when I do open a pull request, it kicks off two builds, as shown in the
image.
What I want is the following:
push remote branch (Travis CI does nothing)
create PR (Travis CI kicks off 1 build)
push commit to the branch (Travis CI kicks off 1 build).
Does anyone know what additional configuration is required to achieve this result? Many Thanks.
The expected workflow can be achieved by disabling the "Build Pushes" feature as described here: https://blog.travis-ci.com/2014-03-05-repository-settings/
Each time I push to Github, it appears to trigger two Travis CI builds - one for the PR and one for the Push itself. They also appear to be separate builds, judging by the links.
What's the exact difference between the two, and how can I enable it so that only one runs?
You can uncheck either building pushes or PRs in the TravisCI settings for the repository:
The difference between them is:
/pr builds automerged state (as if you merged the PR and ran the tests on that, note: it won't run if the PR can't be automerged).
/push builds for the current state of the branch you pushed to (as if you ran the tests on your local copy you just pushed),
What's happening in your scenario looks like this:
continuous-integration/travis-ci/push - only run test on branch
continuous-integration/travis-ci/pr - merge and run tests
And this is completely okay - but if you want to get rid of one of the builds you need to disable Build pushes or Build pull requests in your project settings on Travis.
Sources:
https://github.com/travis-ci/travis-ci/issues/1504
https://github.com/twisted/twistedchecker/pull/93
https://blog.travis-ci.com/2014-03-05-repository-settings/
We are using Jenkins,GerritTrigger setup for CI and it will start build for each commit though all commits came from single push. Since all changes are dependent on each other its enough to make a single build with all changes, but I don't see that option in GerritTrigger plugin.
I believe many companies use Jenkins and Gerrit combination and I am curious to know how they are handling these cases.
Example:
If a developer pushes below 4 commits at once to gerrit it will create 4 changes accordingly in gerrit say 1,2,3,4 and it starts 4 builds in jenkins for all commit
git log --oneline
e3dfdwd CommitD
5fgfdgh CommitC
df34dsf CommitB
a23sdr3 CommitA
Here 4 commits as a whole will pass all tests in jenkins but individually they will fail. Now jenkins builds will fail for A, B, C and will succeed for D as it will checkout A,B,C as they are its dependencies.
In this case though Commit-D is successful it can't be merged as its dependencies are not passed in Jenkins.
It seems reasonable from development to expect jenkins verification for each push instead of each commit. But GerritTrigger can run for each commit only.
Question:
Is there a way to inform jenkins to start build only for commit-D as it will have all dependencies C,B,A ??
Or can we start a build for each git push from development instead of commits?
Sorry if I had any info
I found a way to start build only for commit-D.
I have introduced a gerrittrigger job which runs immediately after every commit, this job will not do any clone/build/verification.
It will just do some set of verifications like, check if given change has needed-by change, dependency exists and dependencies on same branch etc
This job will trigger another main job which does real clone, checkout change, build, verification etc only for changes which pass all validations.
So this will start job always for top commit and approve/reject all dependent changes based on job result.
Though it has few limitations, we found this method is suitable for our workflow
Most companies don't use git and gerrit :) Most companies don't even use git, unfortunately. And most of the ones that do, don't use gerrit. I've consulted for dozens of companies: two use git, and neither of them have even heard of gerrit.
I don't think it's possible to get gerrit to think of pushes as if they were commits. Since each commit in a push can be separately reviewed and rejected, each commit has to be considered and built separately. If you don't want it to work that way, gerrit might not be for you.
Instead, you should squash your related commits locally before pushing them to gerrit. This will achieve the desired results.
On .NET projects, I've used TeamCity and Subversion to run pre-checked builds.
For those unfamiliar with pre-checked builds, the idea is that when you commit, a build is run with your changeset against trunk.
If that build passes, then your changeset is applied to trunk. If it doesn't pass, you're notified and can try again.
That way, builds from trunk should always be green, and no-one else on the team is interrupted by build breakage.
My question is: has anyone achieved a similar workflow on a Ruby on Rails project, using Git and Jenkins (a.k.a. Hudson)? If so, could you please share some hints / tips / documentation?
You might want to have a look at a Jenkins/Gerrit combination. Gerrit is a code review system that you can setup so it will not push your commit to master unless your commit is approved. You can set it up so that Jenkins first has to approve it.
We are starting to use it for a C++ project where Jenkins first tries to build the patch, if it succeeds it is pushed to the main repo. This also doesn't stall git on the client side.
http://jenkins-ci.org/
https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
To truely do this, you want to use a Git pre-receive hook. An excellent one (which runs PHP tests when code has been pushed) is detailed in: a blog post on codeutopia.net
However, the last sentence of the entry states:
it will cause the git push to be delayed until its completion.
Which is no fun if your test suite takes minutes to run, and seriously annoying when it takes 10 or 20 minutes (because git on the dev's machine will sit there and wait and not let go until the pre-receive hook exits).
Now, you may be able to write some sort of Hudson script to revert the failing commit when a build breaks. A former team experimented with such an idea, but never implemented it.
I've setup the Jenkins for the rails3 app to build the specs.
One can find many posts via google on how to setup the build trigger on the github push.
But what I want is to build the new remote branch pushed to Github.
e.g.
I've a repo origin/master. I cloned the repo, created a new branch, did some commits and pushed that branch to origin git push -u origin new_branch
Now I want the Jenkins to build this newly pushed branch on the origin.
If the build is successful, then Jenkins should merge it into origin/master automatically.
The Jenkins plugin has github, git plugin. But it requires to put the branch name. Instead I want to build the new_branch dynamically.
How can I setup such process?
If I remember correctly branch name is not a required entry. You need to test it, but I think if you do not fill it, Jenkins tests all new commit in the repo regardless which branch is affected.
But I recommend you do not merge automatically. You do not want that, trust me. :-)
It seems can not do that with only github and gitgub parameter plugin. If you specify branch_regex*** in Branch to build, Jenkins always build the latest commit in the bunch of branches that it saw. Must specify a branch in order Jenkins to build on the latest commit in that branch. I also see some answer with Multi Branch Pipeline but not sure how to deploy that way. There is no specific instruction at all.