For a some time now I'm thinking about a way to setup a continuous delivery pipeline and don't seem to get my head around it.
I want to auto-create a Github release with a corresponding tag. Plus I want to update the version in a file inside the repo (/docs/antora.yml). The version in the antora.yml should be the same as the tag which I want to create.
Since the source of truth always is the main branch on Github I only want to create tags in the remote repo. Tagging locally and pushing the tag to the remote repo is not an options! Ideally I would like a successful Pull Request to be the trigger. But (as far as I understand) then I always have to create a branch. Plus I don't want every PR into main to create a new release and tag. I want to handpick the PRs.
One way to achieve this would be to create a dedicated release/v1.2.3 branch, run everything from there and auto-create a tag and release. Then a release pipeline could listen to the tag-creation and do the actual e.g. deployment to DockerHub.
What I don't like about this is, that I need a release-branch which kind of moves me further away from working trunk-based. And I need two pipelines: a CD-pipeline which would only handle organizational stuff and a release-pipeline which does the technical deployments.
I would prefer to do everything in a single CD pipeline based on the main branch.
Now I'm very interested in your opinions. Are my thoughts valid or is this some kind of anti-pattern? Do you know some best practices? Maybe someone has an example implementation? I think I can handle writing the actual pipeline code. I'm just not sure how to organize my process. By the way: I already have a CI pipeline working. So to me CD is the logical next step