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>
Go 1.20 will be there soon, I think it's time to move our go.mod to
latest stable. We can then remove the compat in our vendor.Dockerfile
Downstream projects like compose or github.com/linuxkit/linuxkit should
not be affected.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
This change has been introduced in e7b5ee7518
but we should not check context builders when removing inactive
ones.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
We should avoid erroring with attestations support compatability errors
when a user has specified --provenance=false.
A user may wish to enable --provenance=false that works across buildkit
versions, but currently it will fail on old versions - this patch fixes
this, to silently ignore the provenance flag for this check if it's set
to disabled.
Signed-off-by: Justin Chadwell <me@jedevc.com>
The buildx builder persists across Desktop restarts. So when we start up Jaeger, we should recommend that people configure it to persist across restarts as well.
Signed-off-by: Nick Santos <nick.santos@docker.com>
Delay loading the attestation data immediately, and only compute it upon
request. We do this using a deferred function which allows to define the
computation in the same place as before, but perform the computation
later.
With this patch, we ensure that the attestation data is only pulled from
the remote if it is actually referenced in the format string -
otherwise, we can skip it, for improved performance.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This refactor ensures that the attestations are not output in the JSON
output for "{{ json . }}", and additionally allows future refactors to
dynamically load the attestation contents, ensuring faster performance
when attestations are not used in the output.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Using the syncronization primitive, we can avoid needing to create a
separate wait group.
This allows us to sidestep the issue where the wait group could be
completed, but the build invocation functions had not terminated - if
one of the functions was to terminate with an error, then it was
possible to encounter a race condition, where the result handling code
would begin executing, despite an error.
The refactor to use a separate error group which more elegantly handles
the concept of function returns and errors, ensures that we can't
encounter this issue.
Signed-off-by: Justin Chadwell <me@jedevc.com>
CrazyMax