setup-node: 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://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.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 111
- Comments: 114 (6 by maintainers)
Commits related to this issue
- Merge pull request #49 from akamai/develop Develop — committed to krzyk/setup-node by bradforj287 5 years ago
- feat: add PR support (#49) * feat: add PR support * add debug steps * fix: use console * fix: fix buil error * [auto] build: update compiled version * fix: better branch handling * ... — committed to deining/setup-node by EndBug 4 years ago
@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 havepackage: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 orgA 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
inputs
to any shared action. For shared workflows you could usesecrets: inherit
.So all in all this would lead to:
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?
FAIL
FAIL
FAIL
FAIL
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:
@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.
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.
This page now exists voor Node packages as well. I successfully had an action in
repo2
install a package fromrepo1
by using the standardsecrets.GITHUB_TOKEN
, so without PAT. The trick is to addrepo2
with read access inrepo1
’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
.packages:read
permissionREGISTRY_TOKEN
environment variable in .npmrc. For example: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:
dependabot.yml
to include your private repository. For example: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
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:
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:![image](https://github.com/actions/setup-node/assets/113597004/de321374-94ed-449d-af87-5cdc86cd4043)
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:
Are there any news regarding this?
@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
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 :
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):
Having the same issue myself:
npm i
from a github action in the one that fetches the other private module, it saysnpm 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 tonpm 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
withnpm ci
in action, nothing else neededThe 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 😦
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:
.github/access.yaml
file.$GITHUB_ACCESS_TOKEN
environment variable for further usage.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 useIt 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:
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.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 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.