1

I'm currently working on a project that involves continuous integration and deployment. We work using the methods of Git Flow, where a feature/* branch is created to work on functionality, this is then merged into develop after a merge request has been peer-reviewed. Once we want to release a new version, we create a release/x.y.z branch, and once that has been approved, we merge to master.

The issue here is, that the current project requires each new build (so each commit / merge on a release/x.y.z or master branch) to have a unique build number by incrementing the build number. This process works perfectly fine, except for that once something becomes merged to master, we don't merge it back into develop automatically, which means that eventually, we'll have the same build number for similar versions.

We're using GitLab Enterprise, together with GitLab Runners, to run our build process and increment the build number, then commit it back with a [skip ci] tag in the commit message to prevent a new build from being started. I'm familiar with the most regular git commands, but I'm not sure how I could automate the process of merging back the changes from the master branch back into develop, without manually having to merge or create a merge request, and preferably, without cluttering the entire commit history with version bump commits.

What are my options here?

Ruben Rutten
  • 1,659
  • 2
  • 15
  • 30

1 Answers1

0

If you can split the version in a separate file you could keep it in master only. For the release candidates you could build the snapshot. Otherwise you will have to merge matter back to develop...

Dr Phil
  • 833
  • 6
  • 18
  • Unfortunately also release branches are built and released as tests. If someone previously installed the release branch version (with different API endpoints), they can't install the master branch version if the master branch's version isn't higher. – Ruben Rutten Mar 26 '19 at 17:01
  • It means then all branches have to share the same version file. Effectively, the build tools are fighting with git flow. – Dr Phil Mar 26 '19 at 17:10
  • That's not entirely true. Basically, if `develop` is version `1337`, then each commit to `release/x.y.z` would increment that. So by the time the release has it's bugs fixed or is tested, version could be `1340`, which is then released to master as `1340`, which increments it to `1341`. Then I need to close the loop my merging that back into `develop`. We're working with multiple developers so a file that's not inside version control would only cause problems or add another system to maintain, while the goal of our CI setup is to make things simpler. – Ruben Rutten Mar 26 '19 at 17:13
  • periodically merging master to develop is actually the recommended way to go. For example a hot fix done on the master – Dr Phil Mar 26 '19 at 19:53