This patch improves timeout logic for testing and creating a buildx
server. Instead of needing to have a custom loop, we can just use the
primitives provided by go and grpc for easier handling.
Additionally, without the explicit time.Sleeps, we defer to GRPCs
exponential backoff algorithm which should provide substantially better
results.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This signal may be sent using an external tool such as pkill, and since
we can handle it neatly, we should.
Signed-off-by: Justin Chadwell <me@jedevc.com>
When exiting, we should ideally always print a message, and give details
as to exactly what error we received.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We don't know if other builds might be running, etc, so we should allow
the server to decide when to exit.
Signed-off-by: Justin Chadwell <me@jedevc.com>
With changes to the lazy evaluation, the evaluation order is no longer
fixed - this means that we can follow long and confusing paths to get to
an error.
Because of the co-recursive nature of the lazy evaluation, we need to
take special care that the original HCL diagnostics are not discarded
and are preserved so that the original source of the error can be
detected. Preserving the full trace is not necessary, and probably not
useful to the user - all of the file that is not lazily loaded will be
eagerly loaded after all struct blocks are loaded - so the error would
be found regardless.
Signed-off-by: Justin Chadwell <me@jedevc.com>
With changes made to allow lazy evaluation, we were early exiting if an
undefined name was detected, either for a variable or a function.
This had two key implications:
1. The error messages changed, and became significantly less
informative.
For example, we went from:
> Unknown variable; There is no variable named "FO". Did you mean "FOO"?, and 1 other diagnostic(s)
To
> Invalid expression; undefined variable "FO"
2. Any issues in our function detection from funcCalls which cause JSON
functions to be erroneously detected cause invalid functions to be
resolved, which causes new name resolution errors.
To avoid the above problems, we can defer the error from an undefined
name until HCL evaluation - which produces the more informative errors,
and does not suffer from incorrectly detecting JSON functions.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This is now directly handled by our actions-toolkit. We keep
`.github/releases.json` file for now but will be removed on
next v0.11 release.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
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>
Justin Chadwell