Jenkins Rules
From Gcube Wiki
Revision as of 19:31, 20 June 2019 by Manuele.simi (Talk | contribs) (Created page with "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...")
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.