Improved workflows for CI and releases

[Masgalor]

As discussed here #328 and in accordance with #333 this PR fundamentally reworks the workflows used for CI and release-management.

This PR covers every aspect of the meta-issue for this change.
I am aware that this is not how it was outlined in the action plan, but I found it difficult to develop this in individual steps.
My idea for testing this right now is, to create a fork of AsherGlick/Burrito and merge #342 and this PR into it so every scenario imaginable can be tested. That is what I did during development.

We can split this into some smaller PRs, but since I am working with reusable workflows and actions I see this more as a one or nothing change.

That's it for the intro, lets talk about the details.

---

What is the general concept?

First step is to build the git repository as is job: Pre-Build, this is just to get the checksums of the binaries when they are built from the latest commit.
The second step is job: Check, we want to check here if the binaries are different from the last ones, or if we have an untagged commit to create a new release. I know it would be more efficient to check for this before building the reference binaries, but this increases complexity while having no real benefit. If we are sure there are changes warranting a new release we will create a new tag for it.
The third step job: Build will build the binaries again, this not important right now as those would not differ from the Pre-Buildones. But this is necessary to use the new tag to set the right version when building the binaries (in the future).
The final step job: Publish will create a release and write the checksum for every binary to a git-note at the current tag.

---

What individual parts do we have?

Composite action to analyze our git repository

We need some information from our git data all the time, so we use the custom action `repo-state' to generate an overview for us...

• Last tagged version
• Note on the last tag
• Number of commits since the last tag
• Major version number
• Minor version number
• Revision number

Reusable build-job

The build-process is always exactly the same, otherwise we were not able to compare the checksums of the produced binaries.
This job takes care of...

• Downloading and caching the godot installer and templates
• Installing build-dependencies as mingw
• Building everything
• Uploading the built binaries as an artifact
• Creating checksums of everything

Reusable publish-job

If we made it to the publish-stage it is always the same...

• Download the artifacts and package them
• Create a release note
• Create a release
• Write the checksums of the released files to the last tag's note

Create a major release

This is a manually called workflow that creates a major release using the reusable jobs above.
It requires a release-note when triggered by hand and can optionally add the commit messages of the relevant commits.
This workflow can only be triggered by hand, it will abort if there are no commits without tag or if the binaries are the same as with the last release.

Create a minor release

This is a automatically called workflow that creates a minor release using the reusable jobs above.
It is automatically triggered every Tuesday 13h, it does not depend on any inputs, the commit message will be automatically created from the relevant commits.
This workflow will abort if there are no commits without tag or if the binaries are the same as with the last release.

Create a bugfix release

This is a manually called workflow that creates a bugfix release using the reusable jobs above.
It requires a release-note when triggered by hand and can optionally add the commit messages of the relevant commits.
This workflow can only be triggered by hand, it will do anything necessary to make sure a new release is created, no matter if the reference-binaries are the same as with the last release or if there is no commit without a tag. If there is no commit without tag it will create one to make sure there is no commit with two tags at the same time.

---

Notes

We can discuss changes or how to split this in the appropriate issues.
I do not like dependencies to random libraries therefore the only external resources are ncipollo/release-action@v1 and simbo/changes-between-tags-action@v1.

[AsherGlick]

Overall I think we should still split this up into smaller PRs. I want to get this running in production in the order I set out the original issues so we can spend some time making sure everything is working as intended.

Your plan to make a fork that runs these workflows is a good idea and will greatly help with the testing, but I still want to go with my release schedule.

This is likely going to be a giant merge conflict with the workflow changes we made in the xml_converter branch. Those changes split up the compile steps to run in parallel. I'm ok with resolving that conflict so long as we can mostly overwrite the "build" step and apply some of the changes you made, such as caching.

[AsherGlick]

What does ref: master do here? Just guarantee that the were are not looking for tags on branches?

[Masgalor]

The workflow runs per default with the commit that was in HEAD when it started, so checkout will always refer to this commit. This is bad for us, because we change some git-data or add another commit in the process, so we have to tell checkout not to use the context it got from the workflow but to work with the actual HEAD of master.

[AsherGlick]

I don't think I totally follow yet. Isn't this workflow just searching back through the history to find tags and notes? What git data is being changed in this workflow?

[Masgalor]

This action does not add anything, it is read-only, that is correct.
The workflow Release Bugfix might add a new commit during job: Check and add a new release-tag to it if there was no commit after the last tag. If we get to job: Publish we use this action to get the tag that was created earlier. But by default we would neither see the commit nor the tag because they did not exist before the workflow was started. ref: master makes sure we can reach commits that were added during one of our workflows.

[Masgalor]

Found another discussion that might explain this better than I can.
https://github.com/orgs/community/discussions/25985

They solve the problem slightly different, but it will help to understand the underlying problem.