ci: generate releases.json on release event

[crazy-max]

We are currently using the GitHub API in our setup-buildx-action to check for latest and tagged releases to make sure they exist before download. But this requires using a token to avoid rate-limit. It's fine for public runners but GHES runners don't have the github.token populated automatically (see docker/setup-buildx-action#194). They need to create a PAT.

This PR will solve this issue by generating and pushing a releases.json file in this repo when we publish a GitHub Release, see https://github.com/docker/buildx/actions/runs/4033493181/jobs/6934050707#step:3:5

This file will then be fetched through raw.githubusercontent.com endpoint on setup-buildx-action repo. This endpoint is better served for our purpose with 5000 requests per hour compared to the GitHub API endpoint that is limited to 60 requests per hour (unauth) and 1000 request per hour when authenticated.

Also ignore .github/releases.json file on pull request event as an action in a workflow run can't trigger a new workflow run anyway. See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#example-using-more-than-one-event

We could also generate this file within the setup-buildx-action repo if we don't want that in Buildx repo. Let me know what you think about it.

[jedevc]

This SGTM - since this is the only GitHub API we use as part of the action, it makes sense to access the actual release data in the same way as we access the releases themselves. There is going to always be some inconsistency here though - e.g. when tagging a new release, the binaries for that release can't be in the JSON file in the commit we tag (since I think the artifact URL is unpredictable?). That feels kind of annoying, so we should work out how we manage the file - maybe we should only allow modifying it on the master branch (and verify this through CI)?

We could maybe bring this into our actions utility tools when we do that? It seems generic enough that we might also want to use it in some of our other actions, e.g. for buildkit.

Slightly frustrating that this change was made right before the weekend 😢

[crazy-max]

There is going to always be some inconsistency here though - e.g. when tagging a new release, the binaries for that release can't be in the JSON file in the commit we tag (since I think the artifact URL is unpredictable?). That feels kind of annoying, so we should work out how we manage the file - maybe we should only allow modifying it on the master branch (and verify this through CI)?

This will be fine. Currently we are creating a draft GitHub Release:

buildx/.github/workflows/build.yml

Line 201 in a718d07

draft: true

So the workflow updating the releases.json will not be triggered until we publish the release. Will look like this: master...crazy-max:buildx:ci-releases-json

[crazy-max]

Updated to remove the script, bake target and new Dockerfile so we only use GitHub Actions to generate the releases JSON file.

[jedevc]

Suggested change

	commit-message: "update .github/releases.json"
	commit-message: "github: update .github/releases.json"

Or some other prefix, for consistency.

[crazy-max]

github prefix sounds good

[jedevc]

Nice, good to have something reusable 😅

Tiny nit - could we potentially have this produce indented JSON, it would be useful if it was human-readable.

[crazy-max]

Tiny nit - could we potentially have this produce indented JSON, it would be useful if it was human-readable.

Yes might be better, done.

Relevant commit: crazy-max/.github@2a596c9