GITHUB_TOKEN cannot access private packages

Wow! This appeared in set up job section:

GITHUB_TOKEN Permissions
  Actions: write
  Checks: write
  Contents: write
  Deployments: write
  Issues: write
  Metadata: read
  OrganizationPackages: write
  Packages: write
  PullRequests: write
  RepositoryProjects: write
  SecurityEvents: write
  Statuses: write

Are there any news regarding this?

1 Like

I too have come across this hurdle. I have two private Java repositories, one has a Maven action that relies on the artefact deployed to the other repository’s GitHub Package Registry.

My workaround is as follows - Note: this is only good practice for single user private repositories as your Personal Access Tokens (PAT) should not be used by others.

I have added two secrets to my repository (the one dependant on the artefact of the other):


I generated the PAT using the following permissions only:
read:packages (Download packages from GitHub Package Registry)

Below is my action definition

name: Java CI

on: [push]

    runs-on: ubuntu-latest

      - uses: actions/checkout@v2
      - name: Set up JDK 11
        uses: actions/setup-java@v1
          java-version: 11
      - name: Cache Maven packages
        uses: actions/cache@v2
          path: ~/.m2
          key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
          restore-keys: ${{ runner.os }}-m2
      - name: Build with Maven
        run: mvn --batch-mode --update-snapshots --activate-profiles github --settings settings.xml verify
          MAVEN_USERNAME: ${{ secrets.MAVEN_PKG_USERNAME }}
          MAVEN_PASSWORD: ${{ secrets.MAVEN_PKG_PAT }}

And my settings.xml (change USERNAME)

<settings xmlns="" xmlns:xsi="" xsi:schemaLocation="




This issue wasted so much of my time this week. Really would expect this to be fixed by now. Luckily for now I can work around it by (ab)using a PAT.

The PAT workaround works as long as you’re not using services such as Dependabot. Our Dependabot workflow is broken since the first of Mars due to this limitation.

1 Like

Similar to others here, just wasted time trying to move over to Github Packages only to realise I can’t (plus the Dependabot PAT thing meaning even that workaround wouldn’t work).

Is this on the roadmap? The last Staff reply here was in 2019.

We’ve got about a bunch of interconnected repos and this & the lack of org-level workflows (private actions etc) means we just can’t use a lot of the new Github features.

(Looks like the Dependabot PAT thing can be worked around by defining which secrets are ok to pass to Dependabot, but I’d rather avoid that if this is coming at any time)

I am also interested in a soltution here. Currently we are also using PAT to read private organization packages.

It looks like the GITHUB_TOKEN permissions feature has been added: GitHub Actions: Control permissions for GITHUB_TOKEN - GitHub Changelog

but I don’t see anything about OrganizationPackages as this prior post seemed to indicate:

Also can’t find anything in the docs about it.

Looks like this is still an issue?

I haven’t investigated the new Control permissions, so I don’t know if that fixes the above problem or no. I’ve put it on the list of things to do.

In general, I have used a GitHub App and this action (GitHub - tibdex/github-app-token: Impersonate a GitHub App in a GitHub Action) to dynamically generate PATs when I need them, to decent effect.

It’s not solved. The new github token permission per-job settings is great, but it’s missing the organization level stuff still.

We’re publishing a maven package in another private repo, and depend on it in the project at hand. It seems impossible to setup maven so that github actions can build my project because of this dependency.

You are correct that the GITHUB_TOKEN is only going to have permissions in the repo that triggered the workflow. That is for security reasons. You will have to generate a PAT to use to access information in another repository from that workflow.