4 ms·
Absolutely, tasks/system commands should always be stored in VCS as a shell script, so that feature branches can exercise changes in the task itself. Unfortunat
by jquast 11y ago
Absolutely, tasks/system commands should always be stored in VCS as a shell script, so that feature branches can exercise changes in the task itself. Unfortunately theres the other 90% to worry about, and thats where the highest complexity is, such as configuring a build chains, access control, reporting, etc.
Glad to see jenkins is moving towards a travis-ci ".travis.yml" kind of format, but I'm not hopeful to see it catch up to anywhere near TeamCity, even Bamboo in user or developer UX.
- yamitty11 11y agoCould use something like this if you are using github https://github.com/groupon/DotCi https://github.com/groupon/DotCi Job configurations can be version controlled and reviewed like everything else. For multijob pipelines checkout https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin
- techman9 11y agoJJB is also a nice tool that seems like it allows similar functionality (I haven't worked with DotCi, so I can't say how they compare) http://docs.openstack.org/infra/jenkins-job-builder/ http://docs.openstack.org/infra/jenkins-job-builder/
- oblio 11y agoWell... Jenkins 2.0 will provide support for build chains via the pipeline plugin which will be included as a core plugin. Access control can be configured quite nicely with the Role Strategy Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Pl... + AD/LDAP integration. Reporting automation is covered by the pipeline plugin. Custom reporting is quite easy to implement on top of Jenkins, its APIs cover almost everything you need.