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)

CodePudding user response：

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).