fix: add package permissions to push to GHCR#775
Conversation
✅ Deploy Preview for devsydev canceled.
|
✅ Deploy Preview for images-devsy-sh canceled.
|
📝 WalkthroughWalkthroughThe publish job in the GitHub Actions workflow now includes ChangesPackage Publishing
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish-agent-helper.yml:
- Line 31: Update the GHCR authentication flow in the publish workflow to use
GITHUB_TOKEN with the job’s packages: write permission for docker/login-action;
alternatively, if retaining the GitHub App token flow, request and verify
permission-packages: write for the installation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 162fa2da-e585-48bc-b8b9-03bbec225d67
📒 Files selected for processing (1)
.github/workflows/publish-agent-helper.yml
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: read | ||
| packages: write |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Repo files matching workflow:"
git ls-files .github/workflows | sed -n '1,120p'
echo
echo "Target workflow:"
if [ -f .github/workflows/publish-agent-helper.yml ]; then
nl -ba .github/workflows/publish-agent-helper.yml | sed -n '1,120p'
else
echo "missing .github/workflows/publish-agent-helper.yml"
fi
echo
echo "Search for create-github-app-token usages and package-related permissions/workflows:"
rg -n "create-github-app-token|permission-packages|packages:\s*write|packages: write|docker/login-action|secrets\.DEVSY_GITHUB_APP|DEVSY_GITHUB_APP" .github . git ls-files 2>/dev/null || trueRepository: devsy-org/devsy
Length of output: 634
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Target workflow:"
sed -n '1,140p' .github/workflows/publish-agent-helper.yml
echo
echo "Search for create-github-app-token usages and package-related permissions/workflows:"
rg -n "create-github-app-token|permission-packages|packages:\s*write|packages: write|docker/login-action|secrets\.DEVSY_GITHUB_APP|DEVSY_GITHUB_APP" .github . 2>/dev/null || trueRepository: devsy-org/devsy
Length of output: 5748
🌐 Web query:
actions/create-github-app-token v3 permission-packages input GitHub App token packages permission
💡 Result:
In the actions/create-github-app-token v3 action, the permission-packages input is used to explicitly define the level of permission granted to the resulting installation access token regarding GitHub Packages [1]. By setting permission-packages, you can control the scope of the token for packages published to GitHub Packages. The valid values for this input are read or write [1]. Key details regarding the use of permission-inputs: - Purpose: By default, if no permission- inputs are specified, the generated token inherits all permissions currently granted to the GitHub App installation [2][3]. It is a recommended best practice to explicitly list only the permissions required for your specific workflow use case to follow the principle of least privilege [2][4]. - Syntax: To set a permission, you prefix the desired GitHub permission key with permission- (e.g., permission-packages) [2][3]. - Constraints: The permissions you request via these inputs must already be granted to your GitHub App installation [4][5]. If you attempt to request a permission that the app does not have, the action will fail [6][4]. Note that installation-level permissions are set when the app is installed, and if you modify the app's permissions later, an administrator must approve the new permissions before they take effect on the installation [2][5]. - Implementation: Internally, the action maps these inputs (e.g., INPUT_PERMISSION-PACKAGES) to the corresponding GitHub API permission scopes (e.g., packages) [6][3].
Citations:
- 1: https://github.com/actions/create-github-app-token/blob/29824e69f54612133e76f7eaac726eef6c875baf/action.yml
- 2: https://github.com/actions/create-github-app-token/blob/main/README.md
- 3: https://deepwiki.com/actions/create-github-app-token/4.2-permission-system
- 4: https://github.com/marketplace/actions/create-github-app-token
- 5: https://github.com/actions/create-github-app-token/blob/5c1e00d1af39c515564da2ae21cc9dedf0793346/README.md
- 6: https://deepwiki.com/actions/create-github-app-token/4.1-action-inputs
🌐 Web query:
GitHub documentation GitHub App installation tokens permissions packages write create token permission permissions packages: write
💡 Result:
GitHub Apps can be granted a packages permission with read or write access [1]. However, there is a critical distinction between the permissions GitHub Apps can be granted and the functional support for those permissions when authenticating with an installation access token against GitHub Packages registries [2][3]. While the GitHub API allows you to assign packages:write permissions to a GitHub App [1], GitHub App installation access tokens are generally not supported for authenticating directly with GitHub Packages registries (such as npm, Maven, or the GitHub Container Registry) [3]. Attempts to use an installation access token to authenticate with these registries often result in authentication errors (e.g., 401 Unauthorized), as these registries typically require a personal access token (PAT) or a GitHub Actions token [2][3]. The permissions available to GitHub Apps for the REST API include: - Packages (read/write): Controls access to REST API endpoints for managing package metadata, such as listing versions or deleting packages [4][1]. - Note: This permission does not grant the app the ability to perform standard package operations like npm install or docker push against the registries [3]. For workflows involving GitHub Packages, the recommended approach is to use a personal access token (classic) with the appropriate scopes (read:packages, write:packages, delete:packages) [2] or a GitHub Actions token within a workflow environment [3]. If you are building an integration that interacts with package metadata via the REST API, you may be able to use the installation access token, provided the app has the required repository or organization-level permissions [4][1].
Citations:
- 1: https://docs.github.com/en/rest/apps/installations?apiVersion=2022-11-28
- 2: https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages
- 3: Document limitations of using App Installation Tokens with GitHub Packages github/docs#9547
- 4: https://docs.github.com/en/rest/authentication/endpoints-available-for-github-app-installation-access-tokens?apiVersion=2026-03-10
Use GITHUB_TOKEN for the GHCR push.
The packages: write entry only applies to GITHUB_TOKEN, and the app token generated here does not inherit job permissions.packages; its packages capability also comes from the GitHub App installation, not GITHUB_TOKEN. Switch docker/login-action to GITHUB_TOKEN, or keep the App-token flow and ensure permission-packages: write is both requested and granted on the installation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish-agent-helper.yml at line 31, Update the GHCR
authentication flow in the publish workflow to use GITHUB_TOKEN with the job’s
packages: write permission for docker/login-action; alternatively, if retaining
the GitHub App token flow, request and verify permission-packages: write for the
installation.
Summary by CodeRabbit