ci: generate releases.json on release event#1563
Conversation
ec8992a to
bdb8e18
Compare
jedevc
left a comment
There was a problem hiding this comment.
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 😢
This will be fine. Currently we are creating a draft GitHub Release: buildx/.github/workflows/build.yml Line 201 in a718d07 So the workflow updating the |
bdb8e18 to
280391e
Compare
2648807 to
130da48
Compare
|
Updated to remove the script, bake target and new Dockerfile so we only use GitHub Actions to generate the releases JSON file. |
130da48 to
d54ae96
Compare
d54ae96 to
ec5e85e
Compare
ec5e85e to
920f489
Compare
.github/workflows/releases-json.yml
Outdated
| with: | ||
| base: master | ||
| branch: releases-json/${{ github.event.release.name }} | ||
| commit-message: "update .github/releases.json" |
There was a problem hiding this comment.
| commit-message: "update .github/releases.json" | |
| commit-message: "github: update .github/releases.json" |
Or some other prefix, for consistency.
There was a problem hiding this comment.
github prefix sounds good
.github/workflows/releases-json.yml
Outdated
|
|
||
| jobs: | ||
| generate: | ||
| uses: crazy-max/.github/.github/workflows/releases-json.yml@002654044825b3c2b9856af61b8a2aaf389706b1 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
920f489 to
901779f
Compare
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. 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 that 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 Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
901779f to
ea4bec2
Compare
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.tokenpopulated 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.jsonfile in this repo when we publish a GitHub Release, see https://github.com/docker/buildx/actions/runs/4033493181/jobs/6934050707#step:3:5This file will then be fetched through
raw.githubusercontent.comendpoint onsetup-buildx-actionrepo. 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.jsonfile 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-eventWe 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.