GITHUB_TOKEN does not have access to other private packages

[Ignigena]

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://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.

[damccorm]

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

[Phanatic]

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

[Ignigena]

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

[Phanatic]

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.

[Ignigena]

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 🙂

[krystof-k]

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.

[schie]

@Phanatic, any update on this?

[SanderKnape]

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.

[PeterHewat]

As of today, it now works. See #53

[negebauer]

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

[bryanmacfarlane]

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.saobby.my.eu.orgmunity/

Thanks!

[krystof-k]

Posted.

[Alappin]

I posted a follow up issue to reproduce a similar "Error: 404 Not Found" bug on https://github.saobby.my.eu.orgmunity/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?

[krystof-k]

I believe github.community is the right place (unless it is actually related to setup-node action in this repo).

[wpitallo]

Why is this closed, this is a bug

[PatrickHeneise]

@bryanmacfarlane a PAT is "personal" and can't be scoped to a single org, means a PAT has access to all my packages across all my orgs. That's not a solution to me. The GITHUB_TOKEN should have package:read access to all packages in the same org.

[mogelbrod]

Here's another community thread related to this issue.
As of today there's still no solution, only the (unsuitable) Personal Access Token workaround.

[bryanmacfarlane]

@wpitallo - this is closed here because there's nothing that this repo or the code in this repo can do to implement that feature. This is an individual action. Service issues and feature requests are tracked in GitHub community.

@PatrickHeneise package:read won't help here since actions are not packages. They are pulled and run from a repo at the ref specified. Per above there's feature work proposed on the backlog to allow actions to be able to published as packages and other service feature work to control scope of the token (the current behavior is defined as the repo triggering the workflow).

Agreed, the PAT option is a workaround and not a solution.

Hope that helps clarify.

[PatrickHeneise]

Thanks, hope that is implemented soon. We removed our "GitHub service user" when we removed 3rd party CI and build services. Unbelievable that I need to create and pay for a service user again just to have org-level access to packages within the GitHub platform.

[paulmelero]

Having the same issue myself:

• we have 2 private repos under one org that are published as npm packages in the GPR.
• One of them has as a depencency the other one.
• If you try to run npm i from a github action in the one that fetches the other private module, it says npm package "[...]" does not exist under owner "[...]", which is not true, and responds with a 404 error.

Certainly, adding a PAT solved the issue... But having as PAT the secrets.GITHUB_TOKEN should be enough! As it is to npm publish.

I think this is a similar situation as the one described by @Alappin.

[lindsve]

So, it seems I've wasted about two working days trying to figure out why my workflow setup couldn't download packages from other repositories in our organization before I found this issue.

I really can't see the reasoning behind GITHUB_TOKEN not being able to read packages from other internal repositories.

Adding a PAT for now as a workaround, but really hope this is fixed soon

[jozefizso]

@bryanmacfarlane please reopen this and implement a fix for this bug. Authentication with GITHUB_TOKEN against GitHub Repositories is not working.

[bryanmacfarlane]

Per above The GITHUB_TOKEN is created service side and is scoped to the repo. This repository is an individual action for downloading node and the requested feature cannot be implemented here. The topic is covered in this github community post

There is a tracking item for the feature request for the service.

[jozefizso]

That post does not solve the issue at all. Our builds are blocked by this as we cannot install any npm package from our private GitHub npm repository.

[negebauer]

As Bryan says, that's not an issue with setup-node. The current solution (which is not the best in any way) is to create a personal access token to install private packages

[brianjmurrell]

Posted.

This link is now broken. :-(

[spyoungtech]

Expanding upon the guidance provided by @bodograumann -- at the org level package settings, you can enable "internal" visibility for packages. When a package is set to "internal" visibility, all other actions workflows in the org can auth using the builtin github token. This way you do not need to define every individual repository that should have access.

[joebowbeer]

Expanding upon the guidance provided by @bodograumann -- at the org level package settings, you can enable "internal" visibility for packages.

But internal visibility is only available in enterprise, right?

[seuros]

Yes

[spyoungtech]

But internal visibility is only available in enterprise, right?

@joebowbeer I enabled this for my org on github.com -- so, as far as I know, it is available for all orgs.

org -> settings -> packages -> package permissions/package creation

[matt-r-swyftx]

Changing this to 'Internal' still gives me 403 errors. I've copied all of the documentation and advice in this thread. Have people just resorted back to using PAT's?

[florianjr]

At our organization, we were forced to switch to GitLab as personal access tokens don't work for organization npm packages. It's really a mess :(

[sanjaynishad]

changing package availability to Internal works for me
https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#package-creation-visibility-for-organization-members

and just use GITHUB_TOKEN with npm ci in action, nothing else needed

      - run: npm ci
        env:
          NODE_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}

[piranna]

Can somebody explain the difference between private and internal? I don't understand what ones is more restrictive nor why...

[qoomon]

@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)

[piranna]

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.

[qoomon]

@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.

[piranna]

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.

[ErezWeiss]

+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.

[qoomon]

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

[piranna]

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

[NickeZ]

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...

[rick-propelle]

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:

1. 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.

2. 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:
   

3. 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.

[georgiosd]

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.

[duncant3]

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://npm.pkg.github.com/"
          scope: "@org"

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

[ahmadnassri]

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