Upload artifacts as assets of a tip (nightly/latest) pre-release

[umarcor]

This PR is based on #75338, which is a duplicate of #65232. Therefore, it is to be kept as a draft until #65232 is rebased and/or merged.

Currently, users can download artifacts from workflows. However, that requires login and it cannot be easily automated because workflow run URLs are not human-readable. Therefore, they rely on third-party solutions or on manual action to get the pre-built editor and templates with latest fixes.

This PR adds a reusable workflow named tip.yml to be executed after all other workflows are finished and successful, as long as the CI run was triggered by a push to branch master. This workflow downloads all the artifacts, packages the content, computes the sha256sums and uploads everything as assets of a pre-release named tip, which is linked to tag tip. After uploading the assets, tag tip is updated.

As a result, users will have fixed URLs to download the very latest editor and templates, without requiring login.

Step 'Prepare assets' in this PR is just a naive prototype. I would need advice from some maintainer to properly decide which assets to upload and how to name them.

Related:

• Provide PR artifacts and nightly builds godot-proposals#1412
• CI: upload artifacts #42422
• Introduce daily/hourly/bleeding edge preview builds with automatic updates godot-proposals#1458

---

Since the tag is updated, the pre-release in https://github.com/godotengine/godot/releases will always point to the commit that last updated the assets, and the description of the pre-release will be the body of that commit. However, the date will be "wrong". It will be the day the pre-release was created (which some maintainer needs to do before merging this PR). It seems that GitHub does not support changing the date of a release; it must be deleted and created again, which is unnacceptable for tip/nightly because it creates too much noise.

[YuriSizov]

Builds produced by the CI are not suitable for publishing as official releases. They are not compiled with regular flags and optimizations, not all platform combinations are covered, and they are not signed. Therefore making those builds a part of the releases section would be misleading and not useful to most users.

Instead we plan to provide official nightlies in the future, signed and compiled with the appropriate flags for all supported platforms. We will also provide pre-compiled builds of important PRs, suitable for user testing and UX feedback.

PS. In the meantime you can try reviving Calinou's efforts with https://hugo.pro/projects/godot-builds/, but in an unofficial capacity.

[umarcor]

tips are not expected to be comparable to official releases. They are useful in CI, to anticipate for upcoming breaking changes and fixes. All non release assets are for development purposes only.

Is there an estimated time-frame to provide official and signed nightlies with fixed URLs? Actually, I don't care much about being official or signed, as long as the URL is fixed and it does not require login.

I'm not interested in duplicating the build infrastructure outside of godotengine.

[YuriSizov]

tips are not expected to be comparable to official releases

Exactly, but this feature suggestion, this PR doesn't work without publishing the tip as an official pre-release. Which, as I explain, is a problem, because it sends a wrong message about the usability of these builds. If this was done as a dedicated resource, be it a separate repository or a third-party website, then it's not a problem. But there is more to consider when it comes to what we officially publish on the main channels.

There is no ETA for the nightlies, things in Godot development take time to materialize. But thankfully, you don't need to duplicate anything. Everything is already provided for anyone to use as https://github.com/godotengine/build-containers.

Edit: Another approach, if you are okay with build artifacts and not actually production executables, is to use GitHub's own API and extract the links to the artifacts from the master commits. It should be pretty easy to set up and to publish as a GitHub Pages website. I might even do it this week, seems useful.

[YuriSizov]

It should be pretty easy to set up and to publish as a GitHub Pages website. I might even do it this week, seems useful.

Here we go: https://godotengine.github.io/godot-commit-artifacts/
The "Latest" section contains permanent links. It's possible that sometimes not all builds are available (the database is refreshed every hour, but there may be many builds in progress, or artifacts could've expired). But it should make things easier.

[umarcor]

Well, that was an impressive turnaround. I'm speechless 😲

Currently, none of the links is working for me. But, nevermind. I'll close this and we can handle it through issues/PRs in godot-commit-artifacts.

[YuriSizov]

Currently, none of the links is working for me.

Oops, fixed, should be all good now.

An example of a link would be: https://godotengine.github.io/godot-commit-artifacts/download/godotengine/godot/master/android-template/ It redirects to the last available artifact for Android export templates.