Difference between revisions of "Jenkins Rules"
From Gcube Wiki
Manuele.simi (Talk | contribs) |
|||
Line 10: | Line 10: | ||
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ||
+ | |||
+ | [[Category:Continuous_Integration]] |
Latest revision as of 10:42, 4 July 2019
gCube requires the following rules and practices for any Jenkins project:
- a Jenkins project builds always the master branch;
- if a Jenkins project is configured to build a second branch, this branch must generate a software artifact with a different version than master branch;
- the development of new features and bug fixing are done in dedicated branches (task branching);
- merges into master branch are performed when the feature/fix is stable;
- commits are not always pushed to the remote repository, but only when they add a significant, self-contained and consistent piece of working code;
- the master branch MUST be always in a releasable state.
By following them, builds are triggered only when a stable feature is merged into master, while commits in the other branches do not involve Jenkins. If two branches are built at the same time in a Jenkins project (which should be temporary), their different versions guarantee that there are no conflicts in the published artifacts.
Back to the CI guide.