search

abarichello / godot-ci

Docker image to export Godot Engine games. Templates for Gitlab CI and GitHub Actions to deploy to GitLab Pages/GitHub Pages/Itch.io.
https://hub.docker.com/r/barichello/godot-ci
MIT License
759 stars 133 forks source link

Automate image release process #79

Closed TheOrioli closed 2 years ago

TheOrioli commented 2 years ago

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:

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 commented 2 years ago

This looks great, thanks for your work!

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

TheOrioli commented 2 years ago

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 commented 2 years ago

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

TheOrioli commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

cc @TheOrioli

TheOrioli commented 2 years ago

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.