-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GITHUB_TOKEN does not have access to other private packages #49
Comments
@Phanatic any idea why this would work with a PAT but not the GITHUB_TOKEN? |
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 🙂 |
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, 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 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 |
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 Thanks! |
I posted a follow up issue to reproduce a similar "Error: 404 Not Found" bug on https://git.luolix.topmunity/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? |
I believe git.luolix.topmunity is the right place (unless it is actually related to setup-node action in this repo). |
Why is this closed, this is a bug |
@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 |
Here's another community thread related to this issue. |
@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 Agreed, the PAT option is a workaround and not a solution. Hope that helps clarify. |
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. |
Having the same issue myself:
Certainly, adding a PAT solved the issue... But having as PAT the I think this is a similar situation as the one described by @Alappin. |
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 |
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. |
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. |
As Bryan says, that's not an issue with |
Well, now they can sell an additional Enterprise license per org for the robot account 🙃 On a more serious note, why doesn't app accounts work? I can understand that pipeline tokens might have security restrictions around them, but apps can ask for the permissions they need. Still it seems not to work? |
This link is now broken. :-( |
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. |
But internal visibility is only available in enterprise, right? |
Yes |
@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 |
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? |
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 :( |
changing package availability to Internal works for me and just use
|
Can somebody explain the difference between |
|
Thank you @qoomon. Does
|
@piranna you are right |
Good to know, docs and interface are a bit confusing, I don't know why the |
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. |
+1 to @franktcurranvertek I don't want to use a personal token. |
@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:
|
* feat: add PR support * add debug steps * fix: use console * fix: fix buil error * [auto] build: update compiled version * fix: better branch handling * [auto] build: update compiled version * chore: remove debug steps * fix: fetch author using GitHub API when in PR * [auto] build: update compiled version * feat: extend API functionality to non-PR runs * [auto] build: update compiled version
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
|
Based on the documentation, I have my workflow set up to install from my GitHub Package Registry:
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.
The text was updated successfully, but these errors were encountered: