godotengine / godot-commit-artifacts Goto Github PK

I was about to reply in godotengine/godot#75401 when this repository was created, so let's continue the dialogue here.

For context, the motivation of godotengine/godot#75401 was not only to provide tip/nightly/latest builds of godot's master branch in binary format. That's the foundation for providing container images that game/app developers can use for building, testing and deploying their projects in CI (see godotengine/godot-proposals#1411). There should be containers available for both master and stable releases, so they can use the same flow for testing upcoming changes in the tool and for generating the releases with stable versions. For instance:

- uses: docker://ghcr.io/godotengine/export:master
  with:
    args: --export-release '${{ matrix.preset }}' '${{ matrix.path }}'

In godotengine/godot-proposals#1411, the assumption was that maintainers would need to create a user in docker.io and setup the secrets. However, that's not the case anymore. Nowadays, the default github.token allows pushing containers to ghcr.io/godotengine (which is the "Packages" section of this organisation: https://github.com/orgs/godotengine/packages). Therefore, it's only a matter of deciding in which repository we want to have the workflow that builds and pushes the containers.

In reply to godotengine/godot#75401 (comment), I was to ask whether the correct approach would be to have a workflow execute scripts from godot-build-scripts using containers from build-containers. None of those repos has any CI workflow. The default registry in them is registry.prehensile-tales.com, but I don't know whether that's the official registry used for hosting the images used to generate official Godot releases. I believe it would be sensible to have a (maybe weekly or monthly) workflow for building containers from build-containers and pushing them to ghcr.io/godotengine/build. Then, have another workflow to run godot-build-script and push to ghcr.io/godotengine/editor and ghcr.io/godotengine/export.

In this context, I saw godotengine/build-containers#96. I agree with merging build-containers and godot-build-script being sensible. Both have very little content and traffic, are tightly related, and having separated bugtrackers does not provide much benefit. It might be named godot-builds. Since GitHub supports having multiple decoupled workflows in a single repo, the one building the images would be independent from the one using them.

Then, this repository was created. Currently, it provides redirects to artifacts. As a result, a GitHub login is needed. That's not a problem in GitHub Actions, because the default token allows read access to artifacts. However, in order to retrieve those nightlies from e.g. GitLab, credentials need to be managed. Conversely, neither containers nor release assets do require any login at all. Therefore, although this is a nice foundation (particularly given how long it took to bring it up ❤️), I believe we should evaluate how to improve it in relation to build-containers and godot-build-scripts.
Assuming that those two repos are merged into godot-builds, and that we use those to build proper (with regard to flags, signing, etc.) nightly (daily) binaries, would it be feasible to publish them as release assets of that secondary repo and make this page point to those? Should then this page/repo be also merged into godot-builds as the frontend?

Summarising:

• Two workflows need to be created in order to automate building nightly artifacts of the same "quality" as the regular releases. Shall those be contributed to godot-build-scripts and build-containers? Or shall those two repos be merged first?
• Is this repo to be considered standalone or is it to be merge into godot-builds along with the two other?

For context, MSYS2 has been using dummy pre-release assets to host temporary/staging packages for two years now. See msys2/msys2-autobuild, github.com/msys2/msys2-autobuild/releases and https://github.com/msys2/msys2-autobuild/tree/6788467670f5ce71e62db593c2960f051e457f76#automated-build-process.

When curl or get are used to get latest linux-editor-mono or linux-template-minimal, instead of downloading the zipfiles, HTML pages are written. See umarcor@577ee33 and https://github.com/umarcor/godot-commit-artifacts/actions/runs/4548687288/jobs/8019967935:

<!DOCTYPE html>
<html lang="en-US">
  <meta charset="utf-8">
  <title>Redirecting&hellip;</title>
  <link rel="canonical" href="https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309">
  <script>location="https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309"</script>
  <meta http-equiv="refresh" content="0; url=https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309">
  <meta name="robots" content="noindex">
  <h1>Redirecting&hellip;</h1>
  <a href="https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309">Click here if you are not redirected.</a>
</html>

--2023-03-28 23:45:11--  https://godotengine.github.io/godot-commit-artifacts/download/godotengine/godot/master/linux-editor-mono
Resolving godotengine.github.io (godotengine.github.io)... 185.199.108.153, 185.199.110.153, 185.199.111.153, ...
Connecting to godotengine.github.io (godotengine.github.io)|185.199.108.153|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://godotengine.github.io/godot-commit-artifacts/download/godotengine/godot/master/linux-editor-mono/ [following]
--2023-03-28 23:45:11--  https://godotengine.github.io/godot-commit-artifacts/download/godotengine/godot/master/linux-editor-mono/
Reusing existing connection to godotengine.github.io:443.
HTTP request sent, awaiting response... 200 OK
Length: 645 [text/html]
Saving to: ‘linux-editor-mono’

     0K                                                       100% 1.95M=0s

2023-03-28 23:45:11 (1.95 MB/s) - ‘linux-editor-mono’ saved [645/645]

<!DOCTYPE html>
<html lang="en-US">
  <meta charset="utf-8">
  <title>Redirecting&hellip;</title>
  <link rel="canonical" href="https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309">
  <script>location="https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309"</script>
  <meta http-equiv="refresh" content="0; url=https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309">
  <meta name="robots" content="noindex">
  <h1>Redirecting&hellip;</h1>
  <a href="https://github.com/godotengine/godot/suites/11869467969/artifacts/620727309">Click here if you are not redirected.</a>
</html>

I though I might download the JSON files (https://github.com/godotengine/godot-commit-artifacts/tree/gh-pages/data), for instance https://godotengine.github.io/godot-commit-artifacts/data/godotengine.godot.master.json, but I can't see how to get the URL from there without reimplementing the logic.

After the recent changes to the workflow we no longer have multiple top-level workflows that we could use to have nice visual grouping. Instead everything is listed under one group:

It would be nice to restore the previous look somehow, since the actual runs are still split into platforms and whatnot, just like before. We may need to hardcode some of that logic, but that's okay.