Adding automatic release workflow

[pablogarciamiranda]

Automates the version bumping process when creating releases.

When you push a tag, GitHub Actions will:

• Create a GitHub release with the tag message
• Update config/manager/kustomization.yaml with the new version
• Commit and push the change to main

How to release after this PR

git tag -a v0.2.5 -m "Release message here"
git push origin v0.2.5

Everything else is automated.

Test Release

This workflow has created automatically https://github.com/netbox-community/netbox-operator/releases/tag/v0.2.5-test

It has run as expected (created release and version bump commit):
https://github.com/netbox-community/netbox-operator/actions/runs/16464848339/job/46539652934?pr=390
But couldn't push to main because it ran from a feature branch.

This will work correctly once merged.

### After code review

Once the code review is done, I will remove the section that was used for testing and preventing the workflow to pass.

    branches:
      - 'feature/automatic-releases'  # TODO - Remove before merging!
    workflow_dispatch:

[jstudler]

Thanks @pablogarciamiranda

Something that came to mind just now. I understand this will lead to the following commits:

1. first commit, tag 0.0.2 > manually tagged by user, config/manager/kustomization.yaml still pointing to 0.0.1
2. second commit, no tag > created by the pipeline, config/manager/kustomization.yaml now pointing to 0.0.2

I think it would be great if the commit that has the tag attached matches with the tag used in kustomization.yaml. Could we somehow achieve this or is it something we don't want because it e.g. increases complexity? A few ways to do it without any specific preference yet:

• Use the pipeline as is and move the tag to the second commit. We'd have to make sure that either we do not run the pipeline again or we skip it when e.g. the git tag and the tag used in kustomization.yaml match.
• Use a script that is executed locally that takes an argument for the semver level (major, minor, patch), and does everything (bump version in kustomization.yaml, create new commit, tag commit, push). The pipeline would then create the new GitHub release.
• other ideas?

[pablogarciamiranda]

Hey @jstudler ,

Thanks for the suggestions! After thinking a bit into both options...

• Option 1 (moving tags) is easier to implement. We just need to add a few lines to move the tag after the version bump commit. But the problem is that moving tags goes against git best practices (tags should never change by principle), and could create confusion for anyone who already pulled the original tag (unlikely to happen in such a short time, but worth considering)

• Option 2 (local script) is more reliable since everything happens atomically before pushing, so the tag always matches kustomization.yaml. The downside is it's a bit more overhead as developers need to remember to run the script instead of just pushing a tag.

What do you think @bruelea @henrybear327 @alexandernorth @faebr Any preferences?

[faebr]

Hey @jstudler ,

Thanks for the suggestions! After thinking a bit into both options...

* Option 1 (moving tags) is easier to implement. We just need to add a few lines to move the tag after the version bump commit. But the problem is that moving tags goes against git best practices (tags should never change by principle), and could create confusion for anyone who already pulled the original tag (unlikely to happen in such a short time, but worth considering)

* Option 2 (local script) is more reliable since everything happens atomically before pushing, so the tag always matches kustomization.yaml. The downside is it's a bit more overhead as developers need to remember to run the script instead of just pushing a tag.

What do you think @bruelea @henrybear327 @alexandernorth @faebr Any preferences?

We had a short discussion with @jstudler last week and decided that the current implementation is fine. It seems to be common practice to have the tag pointing to the mr and then the kustomization being updated only in the later step. I believe this makes sense since then the actual changes are also in the commit which is tagged.

[faebr]

@pablogarciamiranda can we allign the auto-generated release note sections to be the same as the ones we already have?
See the diff of the sections between https://github.com/netbox-community/netbox-operator/releases/tag/v0.2.6 and the new one: https://github.com/netbox-community/netbox-operator/releases/tag/v0.2.5-test

[alexandernorth]

Hey @jstudler ,
Thanks for the suggestions! After thinking a bit into both options...

* Option 1 (moving tags) is easier to implement. We just need to add a few lines to move the tag after the version bump commit. But the problem is that moving tags goes against git best practices (tags should never change by principle), and could create confusion for anyone who already pulled the original tag (unlikely to happen in such a short time, but worth considering)

* Option 2 (local script) is more reliable since everything happens atomically before pushing, so the tag always matches kustomization.yaml. The downside is it's a bit more overhead as developers need to remember to run the script instead of just pushing a tag.

What do you think @bruelea @henrybear327 @alexandernorth @faebr Any preferences?

We had a short discussion with @jstudler last week and decided that the current implementation is fine. It seems to be common practice to have the tag pointing to the mr and then the kustomization being updated only in the later step. I believe this makes sense since then the actual changes are also in the commit which is tagged.

I would also agree with this approach, that way the tag points to the actual code changes

[pablogarciamiranda]

@pablogarciamiranda can we allign the auto-generated release note sections to be the same as the ones we already have? See the diff of the sections between https://github.com/netbox-community/netbox-operator/releases/tag/v0.2.6 and the new one: https://github.com/netbox-community/netbox-operator/releases/tag/v0.2.5-test

@faebr After having tested and investigated a bit... GitHub's auto-generated release notes always render categories as H3 under "What's Changed", not as separate H2 sections like our current format.

I see the next options

1. Keep GitHub's format... "Version Bumps" stays as ### Version Bumps, and we can create another category for new features or bug fixes. (We could actually try to also reformat the existing ones so we are consistent... there are not many)
2. Post-process them... We can reformat after creation to match the existing style

[faebr]

@pablogarciamiranda can we allign the auto-generated release note sections to be the same as the ones we already have? See the diff of the sections between https://github.com/netbox-community/netbox-operator/releases/tag/v0.2.6 and the new one: https://github.com/netbox-community/netbox-operator/releases/tag/v0.2.5-test

@faebr After having tested and investigated a bit... GitHub's auto-generated release notes always render categories as H3 under "What's Changed", not as separate H2 sections like our current format.

I see the next options

1. Keep GitHub's format... "Version Bumps" stays as ### Version Bumps, and we can create another category for new features or bug fixes. (We could actually try to also reformat the existing ones so we are consistent... there are not many)

2. Post-process them... We can reformat after creation to match the existing style

I think it makes sense to keep the github format. It is probably used in most repo's. Then we can adapt our current ones, you are right its not that many