PRESS0-4760: Fix Satis build failures from GitHub API 429 secondary rate limiting

[arunshenoy99]

Proposed changes

Type of Change

Production

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update
• Refactoring / housekeeping (changes to files not directly related to functionality)

Development

• Tests
• Dependency update
• Environment update / refactoring
• Documentation Update

Visual

Checklist

• I have read the CONTRIBUTING doc
• I have viewed my change in a web-browser
• Linting and tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[github-actions]

AI code review

✅ Strengths

• Swaps SSH repo URLs for HTTPS consistently in both the workflow and satis.json, removing the need for SSH key material in CI and improving reliability on ephemeral runners.
• Adds "no-api": true to each declared VCS repository, which forces Composer/Satis to avoid the GitHub API and helps mitigate 429 secondary rate limit errors.
• Keeps the change narrowly scoped and easy to reason about; JSON remains valid and the repository list is uniform.

❌ Issues (blocking)

• Removing the global config.use-github-api: false introduces a regression for the dynamically provided repository passed via --repository-url in the webhook workflow. That repo is not listed in satis.json and therefore does not receive the per-repo "no-api": true override. As a result, Satis/Composer may fall back to using the GitHub API for that specific repository, which can still trigger the same 429/secondary-rate-limit this PR intends to fix.
  • Action: Please re-introduce the top-level config with at least:

    "config": {
      "use-github-api": false
    }

    Optionally also keep "github-protocols": ["https"] for clarity (even though you now explicitly use HTTPS URLs).

⚠️ Suggestions (non-blocking)

• Consider caching to reduce network churn and build time: cache Composer/Satis VCS clones (e.g., ~/.composer/cache or Satis cache directory if configured) via actions/cache between runs.
• If any repositories can be private in the future, consider constructing the --repository-url with an authenticated HTTPS form to avoid surprises: https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/{vendor}/{package}.git. This won’t be used by the API (given no-api/use-github-api: false), but it ensures git clone has credentials if needed.
• Monitor build duration after enabling no-api: it trades API calls for full git metadata fetches. If runtime grows too much, consider limiting concurrency or selectively excluding repos not needed in certain builds.

Verdict

❌ Verdict: Request changes — Re-add the global config.use-github-api: false so the dynamically supplied --repository-url repo is also protected from GitHub API usage. After that, this should be safe to merge.

[arunshenoy99]

Context on the build currently live on gh-pages

@earnjam @wpscholar @circlecube @andreagrillo

Heads-up for reviewers: the green Satis build currently published to gh-pages was produced by a manual workflow_dispatch run of this branch, not from main.

I rebuilt Satis directly from this branch out-of-band because the AI Store release was blocked by the 429 throttling failures and we were running out of time — rebuilding from the branch unblocked the release ahead of merging this PR.

main still carries the previous (broken) configuration, so the automatic push/webhook builds remain affected until this PR is merged. Merging makes the fix permanent.

[arunshenoy99]

Thanks for the review. The non-blocking suggestions (Composer actions/cache and watching build duration now that we do git fetches) are good follow-ups. On the blocking issue, though, I don't think the regression holds — for two reasons:

1. --repository-url filters existing repos; it can't introduce an unprotected one.
In the webhook workflow, --repository-url is matched by exact string against the repositories already declared in satis.json (PackageSelection.php:910–925), and the build is filtered to the matches. It does not add a repo. Every package the webhook releases is already listed in satis.json, so it inherits that entry's "no-api": true. If a URL ever doesn't match a declared repo, satis throws "Specified repository URL(s) do not exist" (:181) and the build fails — it does not silently fall back to the GitHub API.

2. Re-adding config.use-github-api: false is a no-op — it was already tried and proven ineffective.
That's exactly what #51 did: it added "config": { "use-github-api": false } to satis.json, was merged to main, and the very next build still hit the API and 429'd → https://github.com/newfold-labs/satis/actions/runs/28374584403. satis 2.x does not propagate satis.json's config block down to the VCS drivers, which is precisely why this PR moves to the per-repo no-api flag (read directly from each repo definition by GitHubDriver.php:82). Restoring the global config would look load-bearing while doing nothing.

Net: the per-repo no-api covers every repo satis can build, and the global config the review asks to restore has already been shown not to take effect. Happy to re-add it purely as documentation/defense-in-depth if preferred, but it isn't what fixes the 429.