0

The title is not the best, I agree, please read more details to understand what I mean...

I have a project/repository which has following properties:

  • Commit messages are following Conventional Commits
  • Result of above: there is not single place in the repository which has version number. Versions are calculated automatically based on commits history.
  • History of past "releases" is basically git tags history (when the release is done and 1.2.3 version appears, corresponding commit is being tagged)
  • CI is "simple"/integrated with Github, every merge/push to master triggers full pipeline including deploy/release part (which produces new version, pushes a tag, "makes release" in short)
  • I have no ways (or, I think I have no ways, or I do not want) to trigger the CI manually for release from CI itself. Every trigger should come from git/github.

While this works quite fine in general, my problem is that usually the repo is constant and receives no real new commits, however in some active days I might have 2-3-4-10 new pull requests to be merged.

With the current approach, 10 merged pull requests would result in 10 releases with 10 version increases. But I would prefer to first merge all 10 and then have one release and one version increase.

Any advice, how can I achieve that, what would be the state-of-the-art recommendation here?

One of my thoughts was to have some pre-release or develop branch where I can merge the PRs first and only when it's time to release, merge develop to master. But it looks a bit cumbersome and not really making life easier for contributors (they need to target develop, then I need to create PR from develop to master etc...)

Update:

  • I believe, the answer should be CI-independent. It does not matter which exact CI system is here, what's important is that I don't want to go to CI to trigger the jobs, all interactions should happen via repository. Webhooks/connection between repo and CI is of course available and working.
  • Of course, having said "simple" CI I didn't mean that its configuration is fixed. Of course I can update it in any way I want, no problems with that (trigger on different events from repository, on different branches etc)
The Godfather
  • 4,235
  • 4
  • 39
  • 61
  • Triggering any kind of CI build is CI-system-dependent. There is no generic Git-wide answer to this. Pick which CI system you're using and update tags accordingly. – torek Oct 15 '21 at 11:25
  • @torek I think it does not matter. What matters is prerequisite "I don't want to go to CI and manually trigger the job / I cannot do so". All interactions should happen in the repository (and a CI system is already configured to accept webhooks from repo and this can be configured to whatever I want) – The Godfather Oct 15 '21 at 12:40
  • GitHub's CI system uses GitHub Actions. Bitbucket's CI system uses Bitbucket pipelines. Both use YAML syntax, but what you *put in the .yml file* differs. So it is definitely CI-system dependent. (If you were using Travis, you'd write a `.travis.yml` and commit it to your repository ... using Travis's YML and file name, etc.) (I see you mention GitHub, so I'll edit the tags for you.) – torek Oct 15 '21 at 14:19
  • @torek you misunderstood the question them. I'm not asking "what to write in YAML file"/"how to configure or trigger my CI system". I'm asking about general approach and existing state-of-the-art standards. And no, I'm not using Github actions (nor my question is specific to a given CI system, as I said already), so I'm reverting your edit. – The Godfather Oct 15 '21 at 14:23

1 Answers1

1

There are multiple ways to accomplish what you desire.

One idea you already mentioned yourself:

One of my thoughts was to have some pre-release or develop branch where I can merge the PRs first and only when it's time to release, merge develop to master.

This is the approach that by far takes the least effort. Everything else would require you to change the pipeline. If you are okay with that here are some ideas that are not hard to implement given your current structure:

  • Change the pipeline to not release on every change in the master branch but on every change in the release branch. By that all developers will still be able to target master and you can then squash all the commits and introduce them to release. This approach is simple but depending on the project can lead to issues and/or confusion regarding the git structure.
  • Change the pipeline to not release on every change in the master branch but on every new tag that is pushed. By that you can gather all the commits in the master branch and once you decide it is ready to be release simply push a git tag manually. If you want to go another step further configure the pipeline to automatically create a git tag only if there is a signed commit message by you (or other trusted maintaners) that includes something like version bump to vX.Y.Z. This approach is a more modern one and offers way more flexibility but requires more change in the pipeline than the previous one (keep in mind that changing the pipeline is a one-time effort).
F1ko
  • 3,326
  • 1
  • 9
  • 24
  • Yeah, the first of your bullet is kind of the same as my suggestion, just somehow "reversed". And actually now I think this way (master/release) would be easier/simpler than what I thought at first (develop/master). I have no problems changing pipeline for sure. About the push tag - this contradicts my first item to do not mess with versions manually. In general I don't know which version number will be the next one (like, I know, if I analyze conventional commits since last tag, but that's job of the release automation), so I cannot push tag manually. – The Godfather Oct 15 '21 at 12:43