-
Notifications
You must be signed in to change notification settings - Fork 1.4k
publishing to npm fails after publishing to GPR #52
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
Comments
One thing I notice off the bat is that your registry url is for npm ( |
I am trying to publish from GPR to npm, that's why the URL and token are for npm. |
I also had the same issue, and fixed by creating - run: echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_AUTH_TOKEN }}" > ~/.npmrc
- run: npm publish |
According to the examples provided for this repo for publishing to npm, presumably the The approach of |
Sorry, misunderstood - any chance you can share your package.json file? Also, are you able to publish to npm locally with that package.json file? |
Yes I have been publishing to npm directly (by just commenting out the line in my npmrc that directs the publish to GPR) each time that the github action has failed. Here's the repo (with the package.json): https://github.com/getify/revocable-queue |
I think because this is a scoped package, adding the scope parameter should do the trick. So:
I'm not 100% sure how this will interact with a repo that has a |
I just made the change and bumped the version to 3.0.4 to retry... failed with the same error:
I don't think I have access to that npm debug log, so I can't see anything about why the authentication is failing. :/ |
@damccorm ping |
I have the same problem trying to publish a package to private gemfury - the secrets/NODE_AUTH_TOKEN environment variable is not working correctly. I suspect its being overwritten with XXXXX-XXXXX-XXXXX-XXXXX but its hard to debug https://github.com/actions/setup-node/blob/master/src/authutil.ts adding these run commands to publish-npm helps a little
|
@mpwis nice find! BTW, specifically I think it's this line that could be the problem: https://github.com/actions/setup-node/blob/master/src/authutil.ts#L57 |
Setting the `NODE_AUTH_TOKEN` environment variable doesn't seem to work, trying an npmrc file instead. https://github.community/t5/GitHub-Actions/Installing-npm-packages-from-the-GitHub-package-registry/td-p/30559 actions/setup-node#52
This is a blocker for me to using Github Actions. I would really appreciate some more info on it. |
Not sure that this adds much to the conversation but through the grapevine of (limit) google results and community searching, this has turned into a show-stopper for using Actions and GPR. I'm getting the exact same errors as described above.
Repo in question is https://github.com/paquette/react-components Using the CLI I can publish to GPR no problem, but the authentication fails with Actions -- even though the process is nearly identical and as far as I can tell it's hooked up as documentation suggests. The failing PR (and their associated checks) can be found in this PR https://github.com/paquette/react-components/pull/7 |
@pqt Just to be clear: You’re talking about publishing to GitHub Package Registry only (not the npmjs.org registry)? Because I’ve got that working from within GitHub Actions, with this
In the workflow config, I don’t use any Is that what you’re trying to accomplish or am I totally misunderstanding you? PS: That |
Nope you've got it correct @tjanson, the Going to test what you've got though because it's already considerably more elegant than my 3 different locations of configurations. Gotta sweet case of the GIT mondays going on. (Note the check failure 😂) |
Publishing to GPR from Actions (what @pqt seems to be doing) and publishing to NPM from Actions (which, in my case, is triggered after first publishing to GPR) are separate topics. However, they both seem to have the same symptom, which is that the Action doesn't seem to apply the correct credentials for the publishing (from npm secrets), and/or Actions is not properly using the "registry" setting from the Action. In some cases you can "hack" around this problem by just forcing your own .npmrc, but that's both a hack and runs contrary to the published documentation for this Action, so it shouldn't be "the solution". In my case, since my project already has a npmrc in it, to redirect the initial publish to GPR in the first place, I do not think it's a suitable solution to somehow hack or override that npmrc during the Action to then redirect to npm. |
Yeah, I see the difference now that you mention that @getify. To clarify, my current situation is just trying to publish to GPR at all, which has proven to be unsuccessful out of the gates. I'll stay subscribed to the thread but our approaches seem to be different enough that it might warrant a separate issue entirely. |
@getify even in you're running name: Publish to npm
on: registry_package
jobs:
publish-npm:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v1
with:
node-version: 12
registry-url: https://registry.npmjs.org/
scope: getify
- run: rm .npmrc && npm install && npm publish
env:
NODE_AUTH_TOKEN: ${{secrets.npm_token}} |
As I said up-thread, overwriting (or, as you suggest, deleting) the .npmrc that's in the package is an ugly hack that I don't accept as a proper solution. I am expecting that setup-node figure out how to override my local .npmrc with the .npmrc they're generating, or otherwise redirect the npm publish command to force it to use the generated .npmrc, perhaps in the form of some parameter passed to the npm commands or something like that. GPR requires you to have a .npmrc so that you can publish to GPR using the npm CLI tool. That's the only reason I have a .npmrc in the first place. Since I'm supposed to be able to publish from my command line to GPR, and then have that trigger Actions to publish to npm for me -- the main and indeed only use-case I have for Actions right now -- there needs to be a proper fix for how this setup-node handles the .npmrc files. I shouldn't have to "work around it"; this is supposed to be a first-class supported use-case. |
Perhaps setup-node should not be relying on an npmrc for this config, and should instead inject the |
I have a similar issue. My action looks something like this: name: Release
on:
release:
types: [published]
jobs:
release:
runs-on: ubuntu-latest
name: Release
steps:
- uses: actions/checkout@master
with:
fetch-depth: 1
- name: Install Node dependencies
run: yarn --frozen-lockfile
- name: Build
run: yarn build
- name: Publish to NPM registry
run: npm publish
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} I am getting this error
More details: https://github.com/vega/vega-lite/runs/238298497 |
This npm parameter can force the CLI tool to use a specific .npmrc file, so I think that's the best fix here: https://docs.npmjs.com/misc/config#userconfig The sticky part is, I could do that manually in my So perhaps setup-node could create a .npmrc file in a location, and export whatever path that is as another environment variable, like NPMRC_PATH, and then my script could say:
I think that would fix the issue here in the most reasonable way. |
Just an update, I have tried manually adding the I will probably report this is as a bug to npm. Edit: I'm not positive this is a bug. It might be that npm is indeed using the specified npmrc (the one generated by setup-node) but ALSO using what it finds in my local .npmrc, which sets the @getify namespace to the GPR registry URL. So if that's true, this may either be an issue where the generated .npmrc needs to include my namespace override to point to npm's URL... or it may be that there's a precedence issue, where npm is using the local npmrc in preference over configs it finds elsewhere. If the latter is true, this might not be a fixable problem after all. :/ Edit 2: I am sure now that npm is in fact using the file that I'm specifying with Edit 3: For clarification, I am 99% sure where the authentication error is coming from now. It's because my local .npmrc says: I can't figure out how to get the action to override the |
OK, I think I have finally cracked this problem. I updated my workflow action YAML to have this npm-publish:
That flag has the effect of overriding what's in the local .npmrc that redirected the original publish to GPR, so that actions can now publish to regular npm. |
Use actions/setup-node as actions/npm is apparently deprecated and exits 1: https://github.com/wmde/vuex-helpers/runs/254025692 Publishing (a scoped package) may or may not become a problem this way: actions/setup-node#52
Use actions/setup-node as actions/npm is apparently deprecated and exits 1: https://github.com/wmde/vuex-helpers/runs/254025692 It's a win that this now references a versioned action Publishing (a scoped package) may or may not become a problem this way: actions/setup-node#52
It would be great if publishing worked in a minimal example such as #52 (comment). |
Registry url seems to be ignored here https://github.com/phillmac/orbit-db-managers/blob/a50a35fca7b0d1b79871428b39deb8ecb1293edf/.github/workflows/npmpublish.yml#L40 |
Hi all - here is a workflow that publishes to both NPMJS and GPR, without needing .npmrc workarounds: Just replace Is working at https://github.com/affrae/fib-tools name: Publish to NPMJS and GPR
on:
push:
branches:
- master
jobs:
publish-to-npm-and-gpr:
runs-on: ubuntu-latest
steps:
# Checkout the repo
- uses: actions/checkout@master
# Update package version and set up git
- uses: actions/setup-node@master
- name: Update package version and setup git
run: |
git config user.name "Actions User"
git config user.email noreply@github.com
npm version 1.0.$(date +%s)
# Publish to NPMJS
- uses: actions/setup-node@master
with:
node-version: 12
registry-url: 'https://registry.npmjs.org/'
- name: Publish to NPMJS
run: |
npm config set //registry.npmjs.org/:_authToken=$NODE_AUTH_TOKEN
npm config set scope "<@OWNER>"
npm config list
npm publish --access public
env:
CI: true
NODE_AUTH_TOKEN: ${{secrets.npm_token}}
# Publish to GitHub Package Registry
- uses: actions/setup-node@master
with:
node-version: 12
registry-url: https://npm.pkg.github.com/
scope: '<@OWNER>'
- name: Publish to GitHub Package Registry
run: npm publish
env:
NODE_AUTH_TOKEN: ${{github.token}} |
FWIW, this issue is not about "publishing to both npm and GPR". It's about publishing to npm after publishing to GPR, which in the case of having a .nmprc file, AND the npm package being scoped the same as the GPR package, presents this specific problem I was having. Unclear if others will ever be in exactly that specific scenario. |
I understand - but what if you try my |
I didn't try |
Not sure if this helps, I was also running into this... I was just missing the So your package.json would look like this:
Only add Hope that helps. |
Trying fix from actions/setup-node#52
Hi All, |
I doubt others will be in such a specific situation as I was, especially given now that github owns npm and will probably more closely integrate the two. I expect eventually this is a non-issue. Closing for now. |
I found the solution for this @getify You basically need to publish your package as private |
I am in a very similar scenario. I have been publishing my private package to GPR and now I am taking it public to npm. I have .npmrc in my repo. All attempts to publish to npm after GPR have failed, although I specify my scope, the correct registry, etc... Puzzling. |
I am really not a pro, but it seems you are trying to publish to github packages, and in your .npmrc you have :
Could this be the problem ? |
I have a workflow like this that's supposed to publish to npm once I publish to GPR:
I have the
npm_token
secret added to this repository.When I just published to GPR, it kicked off this workflow job, but it failed at the last step of publishing to npm. The error was from npm saying:
npm ERR! code E401 npm ERR! Unable to authenticate, need: Basic realm="GitHub Package Registry"
What does this error mean, and how do I fix it? I don't see anything about setting "basic realm" in the recipes for this
setup-node
action.The text was updated successfully, but these errors were encountered: