chore: workflow for dev to main

[SilasPeters]

No description provided.

[SilasPeters]

@SamStaijen I added the explanation of the workflow

[stickyPiston]

Do we want to merge via a PR to main? This does cause main to "fall behind and be ahead" of development, since the commit hashes will be different.

[SilasPeters]

Do we want to merge via a PR to main? This does cause main to "fall behind and be ahead" of development, since the commit hashes will be different.

This workflow does not recreate the commits afaik, and I will set a branch rule so that dev-to-main-* branches can only be merged through a PR with rebasing. Thus, the main branch will have the same hashes as development

[stickyPiston]

Be careful though: rebasing through github will still alter the commit hashes, and cause the fall behind and be ahead behaviour. Unfortunately there is no way in github to do this without causing this behaviour.

[SilasPeters]

Then I shall test this, because we did the exact same at https://github.com/team-zomsa/aplib.net, and that worked like I intend to now

[stickyPiston]

Ah, Olaf and I tried to do something similar in static-sticky, but we didn't succeed, so if you manage to get it to work, we can port to other repos as well.

[SilasPeters]

Ah, Olaf and I tried to do something similar in static-sticky, but we didn't succeed, so if you manage to get it to work, we can port to other repos as well.

Bruh @stickyPiston you are right... Let me ask someone who might know more. My guess is that we should rebase through a CLI. Perhaps we can let another workflow rebase with the CLI on approval automatically.