GITHUB_TOKEN does not have access to other private packages

Based on the documentation, I have my workflow set up to install from my GitHub Package Registry:

    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: 10.x
        registry-url: 'https://github.com/proxy/npm.pkg.github.com/'
    - run: npm ci
      env:
        NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

However, I get a 404 when trying to install any private packages scoped to my account with this configuration. Just to clarify these are private packages within the same account that this repo and workflow exists.

Using the exact same configuration, if I replace with a personal access token I've created, I am able to install private packages without issue.

@Phanatic

@Phanatic any idea why this would work with a PAT but not the GITHUB_TOKEN?

@Ignigena

hmm, @Ignigena are the private packages hosted in the same repository as the workflow or are they in another repository under the same account?

The private packages are in another repository under the same account. Both have been published to GPR but as private packages.

Ahh, that's what I figured. The GITHUB_TOKEN we generate is scoped to the repository that is running the Workflow. Unfortunately, this doesn't allow us to install or publish packages from/to other repositories. I'll bring this up in planning and we can figure out how to proceed here.

I figured that might be the case. Would love a solution at least for installing within the same organization. Would rather not have to create a personal access token for each repository -- we're using private NPM modules quite a bit to share business logic/components between all our repos.

We're already forced to do this with NPM's package registry and our TravisCI builds, but was hoping to avoid with Actions and GPR if we can. Totally understand there are probably other implications here, but keep us updated -- would love for this to be as seamless as publishing to GPR is now via an Action 🙂

@Phanatic

This is a huge issue, almost impossible to use Actions CI for us now (without that SSH key fiddling we use now for CircleCI). @Phanatic please keep us posted – token working across the whole organization is a must.

@Phanatic

@Phanatic, any update on this?

This is indeed a big issue and makes working with the Package Registry much harder. It is very inconvenient having to distribute a personal access token that must be set as a secret on each repository. Please give the GITHUB_TOKEN read permissions to all registries in the same organization.

As of today, it now works. See #53

No, it isn't fixed. #53 is about publishing a package, which can be done.
This is about pulling packages from other private repos, which can't be done, it requires a personal access token.

This is also a big issue for me and my company. There should be a way to have an org token that gives read access to the org's packages. Or give GITHUB_TOKEN to other packages of the same org

This is about pulling packages from other private repos, which can't be done, it requires a personal access token.

A PAT is the solution for other private repos.

This also isn't an issue with setting up node (this repo).

If you have a request for the service to expand the scope of the token, please leave feedback on community

https://github.community/

Thanks!

Posted.

I posted a follow up issue to reproduce a similar "Error: 404 Not Found" bug on https://github.community/t5/GitHub-Actions/Package-not-found-in-the-Github-Registry/m-p/31685/highlight/false#M864

What repository do we post GPR related issues like the one i just mentioned above?

@piranna

@piranna

internal means accessible by the whole GH enterprise, that a repository belongs to.
private means only accessible by explicitly configured identities (individual account or teams)

@qoomon

Thank you @qoomon. Does internal apply also for Github Actions? Is internal available for free plans? According to docs, internal seems to be available only for Github Enterprise Cloud:

Repositories in organizations that use GitHub Enterprise Cloud and are owned by an enterprise account can also be created with internal visibility.

@piranna

@piranna you are right internal is accessible by the whole GH enterprise, that a repository belongs to. I fixed my previous comment. Unfortunately it's not possible to grant access just for an whole organization.

@piranna

@piranna you are right internal is accessible by the whole GH enterprise, that a repository belongs to. I fixed my previous comment. Unfortunately it's not possible to grant access just for an whole organization.

Good to know, docs and interface are a bit confusing, I don't know why the internal option appears if I can't use it.

I have written down a post at https://piranna.github.io/2023/05/10/How-to-install-npm-packages-stored-at-GitHub-Packages-Registry-as-dependencies-in-a-GitHub-Actions-workflow/ with the minimal config that's needed to make this work, and explaining why is that way.

@franktcurranvertek

+1 to @franktcurranvertek

I don't want to use a personal token.
The GitHub application returns 401 when trying to download packages from other private repos.
I have both Maven and NPM and only NPM can be internal. maven can't...
So in conclusion we are stuck.

@ErezWeiss

@ErezWeiss maybe the github actions access manager I've developed can help you. Also looking forward for every PR.

Maybe internal packages can help? Although I don't fully understand how the works, they are not intuitive at all...

The github docs has to be better at explaining what one have to do to get private npm packages working across all repositories in an org. I finally made it work with GITHUB_TOKEN, but I have no idea what made it work in the end...

Agree with most that the documentation is confusing and it's difficult to find what you want. Thought I'd leave my findings here.

To control access to packages from other repos in the same or, this documentation here got me over the line. Being able to add repository access to individual packages is cumbersome but works for me. Screenshot of the package settings page where you can add repositories and their permissions (read/write).

Things to note:

There doesn't seem to be a way to enable read access to all repositories in an org at the point the package is published in a github action, so it's is a manual task to set the permissions for each package and repository after it has been created through the github UI.
Setting package visibility to internal rather than private had no effect for me. To clarify, I'm referring to the options in the org package settings, and this does refer to "members", so I'd imagine this only applies to packages being created with a PAT as opposed to packages being created through github actions. Screenshot to clarify:
All the above is through organisation settings, not enterprise settings, since I don't have enterprise. Seems like it's just more cumbersome to work with organisation-wide automatic token authentication (GITHUB_TOKEN) with a non-enterprise account rather than impossible. The fact that it is so cumbersome is still a bit concerning however - it doesn't surprise me that people would resort to using PATs in their github actions which is surely both less-secure and more fallible to misuse.

feat: add PR support (actions#49)

It always amazes me when a source of so much frustration takes 4 years to implement and then the solution is to upgrade to enterprise.

I mean come on, we have like 10 packages and I have to give permissions to each repo we use them in?

I'm all for security but the UX is sub par.

Edit: To add insult to injury, the new fine-grained tokens can be owned by the organization, but there is no permission for packages, so it fails.

Sharing what personally worked for me:

Needed a combination of a few of the different things that people have suggested here. I needed to set the registry and org scope in the setup-node step and in addition to setting my package scope to the Internal which allowed me to use the NPM_AUTH_TOKEN with the GITHUB_TOKEN. I was originally trying without the setup-node step and could not get it to work.

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      packages: read
      pull-requests: write

    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: 18
          registry-url: "https://github.com/proxy/npm.pkg.github.com/"
          scope: "@org"

      - name: Install Dependencies
        run: |
          npm ci
        env: 
          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

for those still chasing this down:

if you set the repository visibility to internal BEFORE publishing your packages, then the package will be published as internal as well (inheriting the repo setting at the time of publish)

then your regular github.token will work for all internal packages

however, if you change the repo visibility setting at a later date, the package visibility WILL NOT CHANGE.

so if you had already published packages, you need to go into them one-by-one and individually set them to internal

I could confirm that, I changed the package visibility to internal and published the package and it works fine.

I have the free edition, No need the enterprize edition.

Navigation Menu

Repository navigation

GITHUB_TOKEN does not have access to other private packages #49

94 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

GITHUB_TOKEN does not have access to other private packages #49

Description

Activity

damccorm commented on Aug 29, 2019

Phanatic commented on Aug 29, 2019

Ignigena commented on Aug 29, 2019

Phanatic commented on Aug 29, 2019

Ignigena commented on Aug 29, 2019

krystof-k commented on Sep 7, 2019

schie commented on Sep 13, 2019

SanderKnape commented on Sep 23, 2019

PeterHewat commented on Sep 24, 2019

negebauer commented on Sep 25, 2019

bryanmacfarlane commented on Oct 16, 2019

krystof-k commented on Oct 20, 2019

Alappin commented on Nov 27, 2019

94 remaining items

qoomon commented on May 10, 2023

piranna commented on May 10, 2023

qoomon commented on May 10, 2023

piranna commented on May 10, 2023

piranna commented on May 10, 2023

ErezWeiss commented on Aug 7, 2023

qoomon commented on Aug 7, 2023

piranna commented on Aug 7, 2023

NickeZ commented on Aug 15, 2023

rick-propelle commented on Sep 26, 2023

georgiosd commented on May 16, 2024

duncant3 commented on Jul 29, 2024

ahmadnassri commented on Sep 11, 2024

tsu1980 commented on Mar 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions