setup-node: GITHUB_TOKEN does not have access to other private packages

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

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!

Why is this closed, this is a bug

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 leave the results of my research here, in hopes someone can verify the information and update the docs for GitHub as-well-as the setup-node action:

Reading private npm packages

1. For each private package that you want to install: define the repositories from which workflows should have read access. https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package Not sure if there is a way to allow more general permissions (e.g. all repos to all packages). Maybe that needs a PAT as before. Btw the new fine-grained tokens (beta) don’t support packages yet.
2. Give the GITHUB_TOKEN read permissions on packages. (This might be unneccesary if you have set your global workflow permissions to permissive and not to restricted. Cf. https://docs.github.com/en/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)

   permissions:
     contents: read
     packages: read
   

3. Use the GITHUB_TOKEN to authenticate with the private npm registry. You can either get it from
   1. The github context:

      env:
        NODE_AUTH_TOKEN: ${{ github.token }}
      

      The upside is that this can be used from any shared action or workflow without restrictions.
   2. Or the GITHUB_TOKEN secret

      env:
        NODE_AUTH_TOKEN: ${{ secret.GITHUB_TOKEN }}
      

      This must be passed down explicitely through inputs to any shared action. For shared workflows you could use secrets: inherit.

So all in all this would lead to:

jobs:
  npm-job:
    permissions:
      contents: read
      packages: read

    steps: 
    - name: Setup node and npm
      uses: actions/setup-node@v3
      with:
        node-version: 16
        cache: npm
        registry-url: "https://npm.pkg.github.com"

    - name: Install npm dependencies
      # Skip post-install scripts here, as a malicious script could steal NODE_AUTH_TOKEN.
      run: "npm ci --ignore-scripts"
      shell: bash
      env:
        NODE_AUTH_TOKEN: ${{ github.token }}

    # `npm rebuild` will run all those post-install scripts for us.
    - name: Run post-install scripts
      run: "npm rebuild && npm run prepare --if-present"
      shell: bash

Yea the only issue with that, is its literally insane that this company insists we use Personally linked tokens to pull packages in our automated pipelines. There should be a way to do this without a dependency on a user account.

As of today, it now works. See #53

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.

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.

So GITHUB_TOKEN does not provide permissions to private NPM packages in a different repository in the same org?

If so, my team’s gonna drop Actions and GH package registry. I don’t want to bind CI to a team member, and I don’t want to pay for a service account for this.

Is there currently a work around for this?

From a GH action, how do you pull an NPM module from another private repo in the same org?

- name: Install NPM Packages
        run: yarn install
        env:
          NODE_AUTH_TOKEN: ${{ secrets.PAT }}

FAIL

- name: Install NPM Packages
        run: yarn install
        env:
          _authToken: ${{ secrets.PAT }}

FAIL

- name: Install NPM Packages
        run: yarn install
        env:
          GITHUB_TOKEN: ${{ secrets.PAT }}

FAIL

- name: Install NPM Packages
        run: echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_AUTH_TOKEN }}" > ~/.npmrc

FAIL

- name: Install NPM Packages
        run: yarn install
        env:
          YARN_NPM_AUTH_TOKEN: ${{ secrets.PAT }}

FAIL

What is the work around??

Github, please listen to your community.

Why setting insecure access tokens (acting on behalf of one single people in an organization) instead of the person directly running the flow with GITHUB_TOKEN ?

Over 2 years later and there’s still no real solution to this. I’m a big fan of not being able to use GitHub Packages on GitHub Actions. 🙃

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.

So I was getting pretty excited about github packages but the concept that all packages are repository scoped and not organizationally scoped appears to be an increasingly tedious approach for managing several dependencies in a project.

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 🙂

Why is this closed? Creating a PAT for a CI action seems like a very ugly solution.

+10000000 Github, please fix this. Microsoft did not purchase you to be deaf to your core users

Understand this isn’t a direct issue of the setup-node action, however I think it’s a common pattern that many users of this action will run into when trying to use GitHub Packages:

- uses: actions/setup-node@v1
  with:
    registry-url: "https://npm.pkg.github.com/"
    scope: "@my-org"
- run: npm ci
  env:
    NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

@bryanmacfarlane, when you say, “There is a tracking item for the feature request for the service.” - is that something users here can upvote or track progress on?

Given personal access tokens can’t be scoped to an organisation, I’d consider this a dangerous and unsupported workaround.

Come on github! Please solve this.

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

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

@domnantas - to add onto your solution / workaround, you can create a bot account (purpose specific account) and a PAT for that to address this concern. Not super convenient, but it scopes access and you can be very specific by granting access to that bot account while limiting scope.

PAT gives access to all my packages across all orgs and I don’t like that.

I think GITHUB_TOKEN with permission: packages:read should have ability to access all private packages in same organization. All are @scoped with organisation and we can publish with GITHUB_TOKEN but can not install in same org. I think this should be rectified. Using a PAT is not the solution.

Container images works with ease, as you can configure it in the “Package settings”:

But this configuration page does not exist for npm packages, and I presume it might not exist for other packages as well.

This page now exists voor Node packages as well. I successfully had an action in repo2 install a package from repo1 by using the standard secrets.GITHUB_TOKEN, so without PAT. The trick is to add repo2 with read access in repo1’s package settings.

It’s also worth mentioning that it did NOT work with packages: read in the job. Only with default permissions.

We had two issues. First, GITHUB_TOKEN does not have access to private packages in other repos (even if it’s the same organization). And second, secrets are not passed to Dependabot, so any actions depending on the secrets will fail.

Here are our solutions: For the first problem, we have used a PAT instead of GITHUB_TOKEN.

1. Follow steps here to create a PAT. Only check the packages:read permission
2. Copy the secret and follow steps here to add the secret to the repository
3. To use the newly created secret follow steps here. For example:

steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
  uses: actions/setup-node@v1
  with:
    node-version: ${{ matrix.node-version }}
- run: yarn ci
  env:
    REGISTRY_TOKEN: ${{secrets.PACKAGE_PAT}}

1. Now you can use REGISTRY_TOKEN environment variable in .npmrc. For example:

registry=https://registry.npmjs.org
@your-org:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${REGISTRY_TOKEN}

This solution isn’t ideal as many already explained in the thread. PAT gives access to all my packages across all orgs and I don’t like that.

If you use Dependabot, its PRs will still fail with the workaround above. As per docs and changelog, Dependabot does not have access to repo secrets. Recently, Github released Dependabot secrets.

So to fix the Dependabot issue:

1. Follow steps here to add a Dependabot secret to a repository. You can use the same PAT you have created in the previous solution.
2. Finally, you’ll need to update dependabot.yml to include your private repository. For example:

  version: 2
+ registries:
+   your-registry:
+     type: npm-registry
+     url: https://npm.pkg.github.com
+     token: ${{secrets.PACKAGE_PAT}}
  updates:
    - package-ecosystem: "npm" # See documentation for possible values
      directory: "/" # Location of package manifests
+     registries:
+       - your-registry

I doubt this is a good solution, but at least now it’s possible to use private repositories, Github Actions and Dependabot.

EDIT: This still does not work for some reason, automatic dependabot PRs still fail due to 401 error

Posted.

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…

I don’t want to be a buzzkill, but the docs specify to use a PAT to access packages from another private repo:

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry#authenticating-to-github-packages

To authenticate to a GitHub Packages registry within a GitHub Actions workflow, you can use:

• GITHUB_TOKEN to publish packages associated with the workflow repository.
• a PAT to install packages associated with other private repositories (which GITHUB_TOKEN can’t access).

Sorry, but GitHub Actions is a mess.

Having a private npm package in a separate repository in the organization is a very common use-case, not something obscure. Yet, for over two years, GitHub doesn’t care about having this workflow streamlined and working as expected.

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.

@Ignigena but that only works for packages in that repo - not packages from another repo within the org

Wow! This appeared in set up job step:

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?

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

As a proof of concept I attempted to setup a GitHub App and authenticate to the private Nuget package repo using a generated “Installation Access Token”.

Did that actually work for you? I tried this and the error message This credential type is not supported for registry. Please use a Personal Access Token or GitHub Actions token instead.

Container images works with ease, as you can configure it in the “Package settings”:

But this configuration page does not exist for npm packages, and I presume it might not exist for other packages as well.

My understanding of today’s situation :

• give read permissions to all my personal repos to members of organization A
• pay 1 extra seat in organization A

Am I missing something ?

Nobody’s reacting on @krystof-k message?

GITHUB_TOKEN Permissions : OrganizationPackages: write

This would solve my problems neatly! Has anyone more news about this?

https://github.community/t/github-token-cannot-access-private-packages/16621/12

As stated in this post, PAT seems have security concern. Binding user specific token to a workflow is not a good practice I guess.

For those struggling to do the same with Yarn 2 (Yarn Berry):

  run: yarn --immutable
  env:
    YARN_NPM_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

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.

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

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

The documentation around this is still really poor, despite the increased support/features that appears to have gone live on the 31st of August. https://github.blog/changelog/2022-08-31-packages-fine-grained-permissions-and-organization-level-publishing-are-now-available-for-the-github-packages-npm-registry/

It’s still not obvious how one can use the “GITHUB_TOKEN” to access an npm package on a separate, private repo.

There is a link here https://docs.github.com/en/packages/learn-github-packages/connecting-a-repository-to-a-package#connecting-a-repository-to-a-user-owned-package-on-github which shows you how to do the connection step, but there the trail runs cold, and I cannot see how in the repo which wants to install the package, how the GITHUB_TOKEN should be used to authenticate to the repo, as it doesn’t just work out of the box.

A new entry has gone onto the GitHub backlog about this yesterday, so looks like there will be a solution coming. I hope it will cover NuGet packages too eventually.

This is affecting our workflow too now. Any updates on fixing this? Seems to be quite a desired piece of functionality. Otherwise I have to move our workflow to circleci in order to support our internal packages.

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

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 😦

github/roadmap#554

There are some additional roadmap listings now for this issue added.

NuGet: https://github.com/github/roadmap/issues/589 Maven: https://github.com/github/roadmap/issues/578 RubyGems: https://github.com/github/roadmap/issues/590

hi, I’ve created a GitHub App and Github Action to workaround these limitations GitHub Actions Access Manager. Feel free to drop some feedback.

The simplified GitHub Action logic is as follow:

• Get GitHub Action Run identity token (signed by GitHub).
• Send this token against an server endpoint that response with a temporary and scoped access tokens based on GitHub App installation permissions. GitHub App needs to be installed in target repository and permissions for source repository needs to be configured in .github/access.yaml file.
• set $GITHUB_ACCESS_TOKENenvironment variable for further usage.

I don’t want to be a buzzkill, but the docs specify to use a PAT to access packages from another private repo:

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry#authenticating-to-github-packages

To authenticate to a GitHub Packages registry within a GitHub Actions workflow, you can use:

• GITHUB_TOKEN to publish packages associated with the workflow repository.
• a PAT to install packages associated with other private repositories (which GITHUB_TOKEN can’t access).

Not a buzkill at all – unfortunately it’s still the truth 😢

Turns out the permissions solution wasn’t actually working – we just had NPM caching those private modules 🙃

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.

I ran into this when trying to access maven releases in github packages. Same idea, unable to access packages in other private repos in the same org using the GITHUB_TOKEN. I agree the documentation could be better for this. Also the error one sees around not be able to access packages in this situation could be a lot better. With that said, I think I’ve got around this with the PAT/secret approach. I don’t really like this, as it’s tied to my account, but it might have to do for now. I believe my org has extra licenses, so until someone teaches me a better way, I might try creating a service account next. I attempted getting this done with github apps, following this tutorial: https://josh-ops.com/posts/github-apps/ . I was really optimistic, but when using the token generated with that strategy I got the same errors saying either unable to find the package (this is the unhelpful error in my opinion), or a 401. It looks like others have attempted using github apps for this purpose. I was hoping my failure was because I wasn’t sure what to use for the username in the maven server config. I’ve tried the installation id, app id, and the github actor (me). Rereading some comments above, it looks like these sorts of tokens might not work with github packages though.

Not sure I’ve added anything valuable, but this ticket did help me realize what my problem was, so even though it’s closed I thought I’d mention that. Thanks folks. Thanks to @davidruhmann for linking https://github.com/github/roadmap/issues/578 . One of my next tasks is getting npm dependencies working, so we’ll see if https://github.com/github/roadmap/issues/554 works as I hope.

Question, if we were trying to emulate the default GITHUB_TOKEN permissions but only ADD the packages:read permission, what would those be? When I tried to use

   permissions:
     packages: read

It broke all my workflows because it removed all my other default permissions. I don’t want to use permissions: read-all for security reasons.

@Phanatic any news on this?

@0Dmitry https://github.com/actions/setup-node/issues/49#issuecomment-542689209 this is not a actions/setup-node issue but a github one

@stoplion this is what worked for me:

jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://npm.pkg.github.com/
      - run: npm ci
        env:
          NODE_AUTH_TOKEN: ${{secrets.PERSONAL_ACCESS_TOKEN}}

where PERSONAL_ACCESS_TOKEN was my PAT that had package:read permissions and I was the owner of the org that I was installing from.

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

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.

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

Yea the only issue with that, is its literally insane that this company insists we use Personally linked tokens to pull packages in our automated pipelines. There should be a way to do this without a dependency on a user account.

totally agree, since we work for company, all token should org / enterprise based, instead of developer account based

I don’t know if this is at all helpful: https://docs.github.com/en/packages/learn-github-packages/connecting-a-repository-to-a-package

Alarming how awful the documentation and support is on this matter, considering most people who use this are enterprise customers.

+1 please fix this. Or at least explain the logic behind this decision, because it is a pretty egregious oversight.

Does the permission OrganizationPackages even exist?

It gives me this error:

The workflow is not valid. .github/workflows/containers.yml (Line: 9, Col: 5): Unexpected value ‘OrganizationPackages’

We had two issues. First, GITHUB_TOKEN does not have access to private packages in other repos (even if it’s the same organization). And second, secrets are not passed to Dependabot, so any actions depending on the secrets will fail.

…

The instructions I’ve written previously allow dependabot to access private package repositories, but actions on dependabot PRs will still fail. We’re running unit tests in a GH Action

Apparently Dependabot PRs are opened as if they are from forks, the secrets are not passed to actions ran from those PRs. It is possible to enable Send secrets to workflows from fork pull requests as explained here, but that opens up a security vulnerablity if your organization has public repositories with secrets as anyone could leak them by adding a malicious action in the workflow and opening up a PR.

It’s a bit weird how 3 Github features (Actions, Dependabot and Private package repositories) are so difficult to configure and in some cases don’t even work without enabling organization-wide security override.

We are facing the same trouble, but with Maven modules. Any pointers are appreciated.