Automate image release process

[TheOrioli]

This PR resolves #65 and #75 by adding a workflow .github/workflows/check-release.yml that runs every night at 23:27 UTC and compares the tag in the latest release of https://github.com/godotengine/godot/releases with the latest tag in this repository. Ideally we would be notified of new releases, but it looks like this would require setting up a repository_dispatch event on the main Godot repo or something similar.

In case the two tags differ, it will automatically create an equivalent tag in this repository and generate a new release. The body of the release is copied from the release in the engine repository.

When a new release is created .github/workflows/release.yml is triggered. This workflow will build the regular and mono Dockerfiles and push the images both to DockerHub and GitHub Container Registry.

The following needs to be added to the repository secrets:

• DOCKERHUB_USERNAME
• DOCKERHUB_TOKEN can be generated in your docker account settings https://hub.docker.com/settings/security
• PAT is a GitHub Personal Access Token, with the following permissions

Naturally, DockerHub allows generating only 1 token for a free account 😅 which together with a limited number of pulls for anonymous users is the reason for adding a push to GitHub Container Registry as an alternative.

[Calinou]

This looks great, thanks for your work!

Out of curiosity, why does the scheduled workflow run at 23:27 UTC specifically?

[Calinou]

Please use ubuntu-20.04 for all runs-on lines instead of ubuntu-latest, so that CI does not break when a new Ubuntu LTS version is released.

[TheOrioli]

Out of curiosity, why does the scheduled workflow run at 23:27 UTC specifically?

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

e: The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.

Thus 23:27, because it's...different 😀

[TheOrioli]

@Calinou Updated all runs-on lines, including the test workflow.

[TheOrioli]

There is an issue caused by GitHub https://github.community/t/github-action-trigger-on-release-not-working-if-releases-was-created-by-automation/16559 not starting any new workflows when triggered from another workflow. The workaround is to use a personal access token to create a release, which would require setting an extra secret in the repository settings. I'll adapt the code in my PR to use the PAT instead of the default github token soon.

[TheOrioli]

Updated the check-release.yml to use a PAT instead of the default GITHUB_TOKEN. Added instructions to the PR description on how to generate one and with what permissions.

[mars3142]

It would be great, if this merge request will be live. Because we are already delayed two patch versions (3.4.2 vs 3.4.4).

[Calinou]

Note: This will take some time to be merged and effective, as I'm looking into creating and assigning the various secrets as mentioned on OP.

[Istalridev]

I might be missing something but it looks like a lot of Godot version variables are still outdated. For example, .gitlab-ci.yml L1 uses 3.4.2, and godot-ci.yml L5 uses 3.3.4. Should those be changed automatically after this PR and the 3.4.4 realease, or should they use latest or a variable instead?

[Calinou]

cc @TheOrioli

[TheOrioli]

I might be missing something but it looks like a lot of Godot version variables are still outdated. For example, .gitlab-ci.yml L1 uses 3.4.2, and godot-ci.yml L5 uses 3.3.4. Should those be changed automatically after this PR and the 3.4.4 realease, or should they use latest or a variable instead?

As far as I could tell those are test files, and since there might be problems when it comes to porting the test export project to different version due to compatibility issues I decided not to mess with it.

IMO the super-correct solution to the "how to test the image question" that would be to create a test workflow that initializes an empty project with the latest image, potentially creates a very basic scene that is almost guaranteed to not get destroyed by a future engine updates and make a build of that.