Arxiu de la categoria: continuous integration
Since some time ago Jenkins, our continuous integration system, already reports back to pull requests the job build status, just like other popular CI systems, there’s some documentation on how to trigger jenkins builds on your pull requests.
Some of you might have noticed that since last week is adding status updates on pull requests to check if the authors of the pull request have signed the Plone Contributors Agreement.
Since today it is also checking if pull requests are modifying the changelog entry file (namely CHANGES.rst), this way, no change will go unnoticed.
Next step is to warn about which pull requests jobs need to be run for a given pull request. With the current three major releases (4.3, 5.0 and 5.1) being tested is quite a challenge to know which major versions a pull request should be tested against.
As usual, please report any problem on jenkins.plone.org issue tracker.
Did you ever got tired waiting a repository (managed by mr.developer) to be cloned?
Wait no more! mr.developer 1.32 comes with two new options to make your life easier:
- a global git-clone-depth option that allows to fetch only the amount of history specified on this option (i.e. git-clone-depth = 1 for only one single commit)
- a per-source depth option that allows to specify the same as git-clone-depth but only for that specific source
What’s the benefit of this? See it for yourself:
git clone https://github.com/plone/buildout.coredev.git test-full du -sh test-full 36M test-full git clone https://github.com/plone/buildout.coredev.git --depth=1 test-shallow du -sh test-shallow 1,5M test-shallow
That’s a 24x saving.
So think about your CI environments where they are downloading over and over the whole repository information while you only care about the very last changes.
Think about some remote environments (mobile connection while you are on a train?)
Update: it seems that is completely broken, sorry for that, working on a fix.
Update 2: mr.developer 1.33 released, thanks @fschulze for the new release!
Thus making it feasible to spot where the problem was introduced, find the changes that were made and report back to the developer that made the changes to warn him/her about it.
A more elaborate step by step description is on our CI rules, be sure to read them!
At the same time though, we use GitHub pull requests to make code reviews easy and have a way to provide feedback and context to let everyone give their opinion/comment on changes that can be non-trivial.
Sadly, pull requests and multi-repository changes can not be tested directly with Jenkins, yes, there is a plugin for that, but our CI setup is a bit (note the emphasis) more complex than that…
Fortunately we came up with two solutions (it’s Plone at the end, we can not have only one solution :D)
Single pull requests
If you have a pull request on a core package that you want to test follow these steps:
- Get the pull request URL
- Go to http://jenkins.plone.org and login with your GitHub user
- Go to pull-request job: http://jenkins.plone.org/job/pull-request (you can see it always at the front page of jenkins.plone.org)
- Click on the Build with Parameters link on the left column
- Paste the pull request URL from #1 step
- Click on Build
Once it runs you will get an email with the result of the build. If everything is green you can add a comment on the pull request to let everyone know that tests pass.
Note: it’s your responsibility to run that job with your pull request and that changes made on other packages after tests started running can still make your pull request fail later on, so even if the pull-request job is green, be sure to keep an eye on the main jenkins jobs as soon as you merge your pull request.
Example: Remove Products.CMFDefault from Products.CMFPlone (by @tomgross)
Pull request: https://github.com/plone/Products.CMFPlone/pull/438
Jenkins job: http://jenkins.plone.org/job/pull-request/80
When the changes, like massive renamings for example, are spread over more than one repository the approach taken before doesn’t work, as the pull-request Jenkins job is only able to change one single repository.
But we, the CI/testing team, have another ace on our sleeves: create a buildout configuration in the plips folder on buildout.coredev (branch 5.0) that lists all your repositories and which branch should be used, see some examples.
Once you have that cfg file, you can politely ask the CI team to create a Jenkins job for you. They will make
a lot of clever things to make that work on jenkins (3 lines change plus following some instructions) and sooner or later a new Jenkins job will show up on the PLIPs tab on jenkins.plone.org.
Rinse and repeat!
Extra bonus and caveats
All Jenkins jobs, be it the pull-request, PLIPs and of course the core jobs, are configured to send an email to the one that triggered the job, so don’t worry about how long do they take to run, once they are finished you will get notified.
The caveat is that the above is only valid for changes targeting Plone 5. We didn’t put the extra effort to make it sure it also works for pull requests (either single or multi-repository) aimed at Plone 4.3. It’s quite trivial to add it for multi-repositories, a bit more work to make it run on single pull requests, still feasible to do if there’s enough people asking for it.
Hopefully the amount of pull requests for Plone 4.3 will decrease more and more as Plone 5 is getting closer and closer one pull request at a time :)
Now there’s no excuse on pushing changes to master without having tested them before on jenkins.plone.org!
Proposals on improvements and suggestions are always welcome on the issue tracker for jenkins.plone.org GitHub repository. Help on handling all those issues are, of course, also welcomed!