Add official build scripts / workflow

[Kaliumhexacyanoferrat]

As a maintainer of the server I would like to use a reproducible workflow to build releases, so that the build does not rely on my machine.

Acceptance criteria

• The process both works for the project and meta packages
• Packages are automatically published to nuget
• The versioning process is still manual (so no automatic commits with new versions or stuff like this)
• The workflow enables project settings such as ContinuousIntegrationBuild
• The process can only be triggered by maintainers

[Matasx]

I think the automation here should be quite straightforward and I think tagging on the main branch with tag containing the version is one way to go. Could you share all the details of the manual process so that it can be captured in the automation? Thanks. 🙂

[Kaliumhexacyanoferrat]

Currently we have, for a regular release:

1. Create a new release branch (e.g. release/9.3)
2. Ensure the correct version numbers in the release branch on all packages (usually a NOP)
3. Create a tag for the release (v9.3.0)
4. Push both
5. Set a new version on the main branch (9.4.0) on all packages
6. Push main
7. Checkout the release branch locally
8. Ensure a clean workspace (git clean -fdx)
9. Build the regular packages (dotnet pack -p:ContinuousIntegrationBuild=true)
10. Build the meta packages (cd Packages && nuget pack GenHTTP.Core && nuget pack GenHTTP.Core.Kestrel)
11. Gather all the nuget packages, including the symbol packages
12. Push them all to nuget
13. Wait for the nuget packages to be indexed and validated
14. Merge the open genhttp-9.3 PR of the website into master
15. Update the website on the server (git pull && docker compose up -d --build)
16. Describe the release on GitHub (e.g. add links to the documentation instead of just issue links)
17. Close the current milestone on GitHub (e.g. "Version 9.3")
18. Create a new milestone on GitHub
19. Update and release all dependent projects as needed (e.g. the templates)
20. Announce the release in the discord channel

For a bugfix release:

1. Fix the bug on main (typically via PR)
2. Cherry pick the commit onto the release branch
3. Update the affected package versions on the release branch as needed (e.g. 9.2.2)
4. Create a tag
5. Push both
6. Perform steps 8-13 above
7. Perform steps 17-18 above

[Kaliumhexacyanoferrat]

So I guess steps 8-12 would be a quick win to be implemented as a workflow, taking a tag name as an input.