Jenkins Rules

From Gcube Wiki
Jump to: navigation, search

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.