Opening this post via this issue.
GITHUB_TOKEN cannot access private packages in GitHub Package Registry, therefore the CI cannot proceed if it includes any private packages.
The only way is to use Private Access Token, but that is binded onto a user and I don’t find this solution as correct (and maybe even not secure) for using it on the CI.
Could the token be expanded to access all private packages within the organization or something like that?
Or having a way to generate organization scoped tokens
Thanks for the feedback. At the moment, as you note, GITHUB_TOKEN is bound to a single repository. We’ll investigate how we might make it easier to have a organization-scoped token in the future. Thanks!
Has there been any progress on this. My organization is having a tough time using Github Actions and GPR otherwise.
Spent a whole day scratching my head as to why I wasn’t able to install another private package I had published within another repository action. An update on this would be very appreciated.
I immediately hit this issue when trying to create and reference private NuGet packages with multiple repos in an organization. Not quite the pit of success I was expecting. I guess I’ll have to reluctantly sprinkle a PAT secret into all organization repos.
@ethomson is there an issue we can follow and up-vote on GitHub?
I never imagined that the built-in token would not have read access to the other packages (in other repos) within the org. When I read in the doc that GITHUB_TOKEN only had access to its own repo, I assumed that only applied to write (publish) access.
In order to use GitHub Actions for building node packages, I either need a read:packages token for the org, or a registry url (opt-in?) that supports it. Then I could use the read-from-org token to install my package, and the write-to-repo token to publish it.
Unfortunately, this makes the Packages feature almost unusable for my org.
Our private packages depend on other private packages frequently.
We aren’t interested in providing our own GITHUB_TOKENs manually (this isn’t sustainable/scalable/secure (no automatic rotation)) or building automation to automatically install+rotate them (investing effort into such a big gap seems like a bad call, because it’s hard to take the feature seriously).
We have packages on Appveyor and use the account-wide feed for CI jobs and it works great. I appreciate that the ACLs on GitHub are more flexible than Appveyor (our org has default read permission for users) and that might make implementing this trickier.
We’ve run into the same issue. I’ve been looking into hosting NPM packages on GitHub as an alternative for our current repository since the CI features seem much more lightweight and easy to maintain than what we’re currently using.
We have packages which depend on private packages, and the inability to access these packages using the GITHUB_TOKEN combined with the fact that we can’t create a token for our organization is a big strike against using GitHub CI.
This is a problem for us as well. Basically makes github packages unusable for us. Please allow the token to read from any repo in the organization.
For personal users, a personal access token makes sense, e.g. reading from @yanneves/my-package in a personal repository. But for organisations, a personal access token is not restricted to one organisation, so I could compromise another organisation’s private packages by using the token for one organisation. Plus, if the personal access token owner leaves the organisation, dependent actions would suddenly fail. I’d consider the personal access token to be a dangerous and unsupported workaround.
A safer workaround is to use a dedicated automation user (e.g. my-org-bot) to house these personal access tokens. This was common practice on legacy organisation accounts but will come at a premium (per-user pricing) on current organisation accounts, required for private repository actions and packages. At the moment, this implementation to use Github Actions with private Github Packages is not fit-for-purpose for organisations.
This is really very sad. Just too sad. I just ran into this same issue with private repositories that git action cannot access. Spent days combing internet for solutions.
Is Github not going to look into this issue and provide workaround? And BTW, I just tried out @yanneves solution but still no luck. Its very frustrating.
FYI I contacted GitHub support about this limitation a few days ago and this was their response:
Thank you for your feedback. We have an internal feature request to change this behaviour and I have added your comments to it. I can’t give you an ETA on when or if it will be implemented. Please keep an eye on our blog and community forums for news about this.
This limitation is the primary blocker to us using GitHub Actions/GPR as well. I scanned through their public roadmap and it’s not there yet, BTW.
Thanks for the update. What can one really do now at least for now? We can’t stop working because of this.
Is this actively being worked on? Is there somewhere we can see the status or timelines? This is also a major blocker for my org. It seems like it was designed to only work in a mono-repo setup?
I submitted a bug report here to add my +1 because this is a huge PITA for everyone but it doesn’t appear to well appreciated.
It’s been a year since this was reported and the public roadmap doesn’t have any mention of this either
@ethomson Could you please provide an ETA on when this is planned?
How do you solve this?
From a GH action, how do you pull an NPM module from another private repo in the same org?
Ok, but how do you actually do it??
What are the steps. Where does it go?
There are the things I’ve done thus far…
- 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
What is the work around??
This is unbelievable that GITHUB_TOKEN is not organization scoped at almost 2021.
Almost teared my hairs off my head. Thanks god that I am the organization owner so my PAT will work. This is crazy.