compat-check: resolve avocado CLI version once per run, not per leg - #35
Merged
Merged
Conversation
The rubikpi3 @ 2024/edge cell of the compat-check matrix failed at "Install avocado CLI" with `curl: (22) The requested URL returned error: 403`. The composite action resolves `version: latest` by querying `api.github.com/repos/avocado-linux/avocado-cli/releases/latest` unauthenticated, and that endpoint shares a 60-request/hour budget across every GitHub Actions customer on the runner's IP range. This workflow fans out to roughly 90 matrix legs per run, each making that same unauthenticated call independently, so one of them losing the race was a matter of when, not if - confirmed by checking the endpoint directly: 60/hour unauthenticated vs 5000/hour with a token. Resolve the version once in the plan job instead, using an authenticated `gh api` call (the job's own GITHUB_TOKEN raises the budget to 5000/hour), and thread the result to every cell job's "Install avocado CLI" step via a new `avocado_cli_version` output. This keeps the "always test against the latest release" behavior the workflow wants, rather than trading it for a hardcoded version that would need manual bumps, while cutting the unauthenticated call count from ~90 to zero. Signed-off-by: Javier Tia <javier@peridio.com>
lee-reinhardt
approved these changes
Sep 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #33
Description
CI job
rubikpi3 · rubikpi3 @ 2024/edgefails at the "Install avocado CLI" step withcurl: (22) The requested URL returned error: 403. This is not a rubikpi3-specific or content-specific failure - it's a GitHub API rate limit.setup-avocado-cli@v1resolvesversion: latestby curlinghttps://api.github.com/repos/avocado-linux/avocado-cli/releases/latestunauthenticated (60 requests/hour, shared across every GitHub Actions customer on the runner's IP pool).compat-check.ymlfans out to roughly 90 matrix legs, each independently making that same unauthenticated call in its own "Install avocado CLI" step. Any leg can lose that race; this run it was rubikpi3.Acceptance criteria
compat-check.yml's cell jobs no longer make an unauthenticatedapi.github.comcall for version resolution.Implementation notes
Fixes
avocado-linux/references@main::rubikpi3 · rubikpi3 @ 2024/edge::(CI break, tracked viadevtool ci-watch).Fix: added a "Resolve avocado CLI version" step to the
planjob using an authenticatedgh apicall (the job's ownGITHUB_TOKEN, 5000 requests/hour), and threaded the result to everycelljob's "Install avocado CLI" step via a newavocado_cli_versionjob output - instead of each of the ~90 legs re-resolvinglatestunauthenticated. Still tracks the newest CLI release automatically; no version is hardcoded.Root cause confirmed from the actual job log (
gh api repos/avocado-linux/references/actions/jobs/106018692872/logs), not the CI-log excerpt the tracking issue was filed from - that excerpt only captured an unrelated post-job cache-cleanup warning and missed the real failure.Not verified end-to-end in CI (no
actionlintin this repo to dry-run the workflow). Validated the YAML parses (python3 -c "import yaml; yaml.safe_load(...)") and thatyamllintreports no new warnings beyond pre-existing line-length style ones, plus a manual line-by-line diff review.Sibling risk, not fixed here:
build-check.yml:123'sbuildjob uses the identical unpinnedsetup-avocado-cli@v1pattern in its own matrix. It hasn't broken yet, likely because it runs a smaller/less concurrent matrix on PRs, but it carries the same latent exposure to this rate limit.