Skip to content

ci: fix 401 resolving MrCrayfish GitHub Packages deps - #4

Merged
KP2048 merged 3 commits into
1.21.xfrom
fix-ci-maven-github-token
Aug 6, 2026
Merged

ci: fix 401 resolving MrCrayfish GitHub Packages deps#4
KP2048 merged 3 commits into
1.21.xfrom
fix-ci-maven-github-token

Conversation

@KP2048

@KP2048 KP2048 commented Aug 4, 2026

Copy link
Copy Markdown
Member

Summary

CI's `check` job was failing at dependency resolution (before any test ran) with:
```
Could not GET '.../catalogue-common-1.21.1-1.11.0.pom'. Received status code 401 from server: Unauthorized
```
`build.gradle.kts`'s MrCrayfish GitHub Packages Maven repo block reads `GITHUB_ACTOR`/`GITHUB_TOKEN` via `"github_actor"/"github_token".localOrEnv`, but neither was ever passed into the `Run check` step's shell environment - so the request went out unauthenticated and GitHub Packages 401'd (it requires auth even for public package reads).

Added both as job-level `env:` so every step (including `Run check`) inherits them.

Heads up - this may not be fully sufficient on its own: `secrets.GITHUB_TOKEN` is scoped to this repo, and cross-owner GitHub Packages reads commonly need a real PAT (with `read:packages`) that's been granted access to MrCrayfish's packages specifically. If CI still 401s after this merges, that's the next thing to check - likely needs a dedicated PAT stored as a repo secret and swapped in for `GITHUB_TOKEN` in this same env block.

Test plan

  • YAML validated (`python3 -c "import yaml; yaml.safe_load(...)"`)
  • Confirm the next CI run on this PR gets past dependency resolution (watch for the same 401 vs. a new failure mode)

🤖 Generated with Claude Code

The MrCrayfish GitHub Packages Maven repo in build.gradle.kts reads
these via "github_actor"/"github_token".localOrEnv, but neither is
auto-injected into a run: step's shell environment - so that repo's
dependency requests (catalogue-common, etc.) went out unauthenticated
and GitHub Packages returned 401, failing dependency resolution before
any test could run.

May not be fully sufficient on its own: the default GITHUB_TOKEN is
scoped to this repo, and cross-owner GitHub Packages reads commonly
need a real PAT with read:packages granted access to MrCrayfish's
packages specifically. If CI still 401s after this, that's the next
thing to check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings August 4, 2026 16:30

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the GitHub Actions check workflow to export GITHUB_ACTOR/GITHUB_TOKEN into the job environment so Gradle can authenticate to MrCrayfish’s GitHub Packages Maven repo during dependency resolution, avoiding CI failures caused by 401 Unauthorized responses.

Changes:

  • Add job-level env exports for GITHUB_ACTOR and GITHUB_TOKEN so ./gradlew check runs with the credentials build.gradle.kts expects.
  • Document the rationale and known limitations (may still require a PAT with read:packages for cross-owner package access).
Suppressed comments (1)

.github/workflows/check.yaml:43

  • Setting GITHUB_TOKEN at the job level exports it to every step and 3rd‑party action in this workflow, which increases blast radius if any step/action is compromised. Prefer scoping the token to only the Gradle invocation that needs GitHub Packages auth (e.g., env: on the “Run check” step).
      GITHUB_ACTOR: ${{ github.actor }}
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .github/workflows/check.yaml Outdated
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
maven.resourcefulbees.com now 200s with an HTML redirect page (to
maven.knifepoint.net) for paths it doesn't actually mirror, instead of
404ing. Since it was declared unscoped, Gradle tried it for every
unresolved dependency, including androidx.collection/androidx.annotation
(pulled in transitively by Compose Desktop's runtime), and hard-failed
trying to parse the redirect HTML as module metadata instead of falling
through to a repo that has them.

- Scope the resourcefulbees repo to the one group it's genuinely still
  needed for (earth.terrarium.common_storage_lib).
- Add google(), scoped to androidx.*/com.android.*, since that's where
  those artifacts actually live (mavenCentral 404s on them).

Verified locally: :Archie:fabric:dependencies --configuration
bundleRuntimeLibraryConfiguration now resolves cleanly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants