One private package gets "404 Not Found" during workflow NPM install step; others fine

I have the following workflow:

    runs-on: ubuntu-latest
      NODE_ENV: development
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
          node-version: '12.x'
          registry-url: ''
          scope: '@mycompany'
          NODE_AUTH_TOKEN: ${{ secrets.GIT_PACKAGE_TOKEN }}
      - name: Install dependencies
        uses: bahmutov/npm-install@v1
          NODE_AUTH_TOKEN: ${{ secrets.GIT_PACKAGE_TOKEN }}

In my repo, in addition to numerous third-party dependencies, I have three private packages that are hosted in my organization’s GitHub Package Registry and are scoped with @mycompany.

The GIT_PACKAGE_TOKEN secret is an organization secret that provides the ability to read/write to GPR.

When the “Install dependencies” step runs, it errors with the following message:

npm ERR! code E404

31npm ERR! 404 Not Found - GET

32npm ERR! 404

33npm ERR! 404 ‘@mycompany/my-problem-package@1.40.0’ is not in the npm registry.

34npm ERR! 404 You should bug the author to publish it (or use the name yourself!)

20npm ERR! 404

21npm ERR! 404 Note that you can also install from a

22npm ERR! 404 tarball, folder, http url, or git url.

I’ve confirmed GPR has the version of the dependency that I’m trying to install.

I also removed that dependency from my package.json and when I do that, the “Install dependencies” step is successful.

What’s interesting is that I temporarily created a Personal Access Token (PAT) and when I attempted to use that as the NODE_AUTH_TOKEN on a step that just runs npm install @mycompany/my-problem-package, it worked.

So it seems like there is a problem using the GIT_PACKAGE_TOKEN only on the one package. Why?

1 Like

We were able to figure out the issue and I’m going to share it here because it’s a really sneaky one. :slight_smile:

This topic clued us in to the answer: Token with "repo" scope to install private packages? - #2 by jcansdale. Specifically this part (emphasis mine):

What I suggest you do is create a machine-user 11 account that has access to the private repositories you need to share packages from (it only needs read access). You can then generate PATs with the read:package scope from this account.

So in my case, my organization creates secrets under a “system user” account and I had not given this user permission to my one repo.