Pulled from our readme...
Plone coredev is currently triggered on each github commit to the core repo
no matter to which branch. This leads to load problems on jenkins.plone.org.
As far as I understood the discussion on that topic the best way to
accomplish this is a small piece of component that sits in between github
and jenkins and can decide which commit should trigger a build. Another
option might be a Jenkins plugin. Any thoughts/ideas?
=> UPDATE: If we disable the "Cross Site Request Forgery" setting in the
Jenkins configuration, the GitHub post-commit hook works.
=> UPDATE: A user "github" has been created in the Plone LDAP and granted
the right to build a job on jenkins.plone.org. See
for an example of a post-commit hook configuration. Anonymous users are
not allowed to trigger a build.
The more I think about it, the more I like the idea of having a Jenkins job for each of our core packages.
If we had some sort of script/job/service that could check the sources.cfg of our coredev builds (PLIPs, other packages?), Jenkins could fire of only those buildouts that matter.
The 1 job/package setup would also allow me to check things like the changelog for proper formatting. It'd make my life easier at release time. Theoretically, we could release packages from Jenkins at some point to, but that's of low priority at the moment.
Or, we automate the creation of jobs, run at regular intervals, to create one job per package per branch. On creation, the job would be tied into the proper coredev job.
Script runs... plone.app.layout has 2.1 and master branches. It creates job plone.app.layout-2.1 with post-build triggers for plone_41 and job plone.app.layout-master with post-build triggers for plone_42.