setup-node icon indicating copy to clipboard operation
setup-node copied to clipboard

Change of registry is being ignored

Open piranna opened this issue 1 year ago • 24 comments

Description:

I'm publishing a package to both GPR and npm, in that order. Execution of setup-node works well, but publishing to npm fails because it's still trying to do it to GPR.

Action version: v3

Platform:

  • [x] Ubuntu
  • [ ] macOS
  • [ ] Windows

Runner type:

  • [x] Hosted
  • [ ] Self-hosted

Tools version: Default ones.

node: v18.16.0 npm: 9.5.1

Repro steps:
Workflow available at https://github.com/Mafalda-SFU/mediasoup/actions/runs/5129548473/jobs/9227484918

Use setup-node with default registry-url, and npm ci works ok. Use again setup-node with GPR registry-url, publish works ok. Use again setup-node with npm registry-url, publish fails because it's still using GPR registry. I've reviewed the code, and by https://github.com/actions/setup-node/blob/869f4dd0c7f320ae834c2724d92a364de3893c24/src/authutil.ts#L39-L44 previous one should have been ignored, or at least it should have been overwritten later at https://github.com/actions/setup-node/blob/869f4dd0c7f320ae834c2724d92a364de3893c24/src/authutil.ts#L51.

Expected behavior: Second call to setup-node defining registry-url should update it for all the next commands.

Actual behavior: Once registry-url is set, it's being preserved for all the next commands.

piranna avatar May 31 '23 08:05 piranna

Hello, @piranna ! Thanks for filing the issue, we will take a look at it :)

dusan-trickovic avatar May 31 '23 09:05 dusan-trickovic

Hello, @piranna ! Thanks for filing the issue, we will take a look at it :)

Welcome :-)

piranna avatar May 31 '23 09:05 piranna

Hello again, @piranna ! I've looked into this issue and I think I may have a potential solution to suggest. Have you tried setting scope to your GH and NPM registry username (respectively) as input for setup-node when you're trying to set / change registries? It could be an important setting to make, as I see that, for one reason or the other, it is failing to authenticate you once you try to publish it to NPM.

In addition to that, another step that seemed to have worked for me was to append to .npmrc directly in the workflow, like:

echo "//registry.npmjs.org/:_authToken=${{secrets.NPM_TOKEN}}" >> .npmrc

However, I would like to add that the latter step might not be necessary at all, so you can try just setting the scope for both GHR and NPM first, and then try combining it with the other suggestion.

Edit: I forgot to add this in my previous version of this reply, but please also make sure that your NPM token is properly configured (for automation primarily) and that it has been added as a repository secret in your Settings.

If this doesn't solve your problem, please feel free to reach out again and we will try to investigate further. Alternatively, if this proves to be successful, you can, of course, also ping me and let me know :)

Thank you very much for your patience and cooperation!

dusan-trickovic avatar Jun 09 '23 09:06 dusan-trickovic

Having same issue

brachkow avatar Jun 09 '23 18:06 brachkow

In addition to that, another step that seemed to have worked for me was to append to .npmrc directly in the workflow, like:

echo "//registry.npmjs.org/:_authToken=${{secrets.NPM_TOKEN}}" >> .npmrc

I think this can confirm something odds is happening. I believe correct solution should be to fully overrewrite the .npmrc file, but another good option would be to append the entries and have defined several entries, or also parse and update the file.

make sure that your NPM token is properly configured (for automation primarily) and that it has been added as a repository secret in your Settings

Yes, it is, because if I comment the first publish step pointing to GPR, it correctly publish it to NPM.

OTOH, what I have seen in the several examples and templates is that publishing is being done in an independent job using a published artifact, so that can be the reason why my use case (change the registry multiple times) has been overlooked.

piranna avatar Jun 09 '23 20:06 piranna

@piranna understood, thank you for the follow-up! Just to confirm, have you tried setting the appropriate scope in any case (for both GHR and NPM registry, but primarily for NPM since it seems to be the problematic one here)? I'm only asking because it has been failing for me as well when I was performing the repro steps (and with the same error) until I set the scope properly, so I thought mentioning that could possibly help solve this problem.

In any case, we will also consider the first part of your reply (about working with .npmrc) and see what can be done on that front. We appreciate the suggestion :)

Thank you for your timely feedback, patience and cooperation!

dusan-trickovic avatar Jun 09 '23 21:06 dusan-trickovic

@piranna understood, thank you for the follow-up! Just to confirm, have you tried setting the appropriate scope in any case (for both GHR and NPM registry, but primarily for NPM since it seems to be the problematic one here)? I'm only asking because it has been failing for me as well when I was performing the repro steps (and with the same error) until I set the scope properly, so I thought mentioning that could possibly help solve this problem.

No, I have not tested it yet, I've been all the day out of computer, I'll try to find some time but anyway I think that's not the problem, and setting the scope would be a by-pass of the problem, or at most a showcase that the problem is exactly on that part of the code.

In any case, we will also consider the first part of your reply (about working with .npmrc) and see what can be done on that front. We appreciate the suggestion :)

Great, you are welcome :-) I would have already provided a PR myself but don't fully understand how that part of the code works, but definitelly I'm pretty sure the problem is in that lines. Maybe it's an obscure bug that's easy to overlook.

piranna avatar Jun 09 '23 21:06 piranna

@piranna we will look into the code and see what can be done :)

In any case, I thought that trying to set the scope here, at least in the meantime and if effective, could be an immediate solution for this issue. I will consult with the team further and see if anything should be done with this functionality either way.

Thank you again! If you're experiencing any further issues related to this one or any other (or if my suggestions solve this one for you, once you get the chance to try them out), please feel free to reach out and let us know :)

dusan-trickovic avatar Jun 09 '23 21:06 dusan-trickovic

Somehow manually creating .npmrc on every workflow step doesn't help

brachkow avatar Jun 10 '23 19:06 brachkow

Hello, @piranna and @brachkow ! Just wanted to ask for a bit of a follow-up to see if anything has changed for you in regards to this? I will try to investigate it further, but I just wanted to make sure that the scope wasn't the issue to begin with (and also if there are any newer updates that occurred in the meantime)? I also let my team know about your suggestion, so we will also look into that a bit further as well :) Thank you for your patience and the valuable input!

dusan-trickovic avatar Jun 16 '23 10:06 dusan-trickovic

I ended up publishing everything manually:(

brachkow avatar Jun 16 '23 10:06 brachkow

Not in my side, this is por a personal side project (https://mafalda.io) and I'm currently looking for a new job, so was not able to get time into it. Anyway, it's easy to reproduce, an unit test following the steps I commented on the issue can show it, as I've said, I think it was not showed before because maybe the normal use case is to do the publishing to the multiple registries in new jobs, so they start clean state.

piranna avatar Jun 17 '23 08:06 piranna

https://github.com/Mafalda-SFU/mediasoup/actions/runs/5514736670/jobs/10054718264

Issue IS still happening, this failed workflow job IS of today. Other projects I've been used parallel jobs for the publish as the action IS intended and they works flawless, definitely the problem is that old credentials are not being replaced by new ones.

piranna avatar Jul 11 '23 03:07 piranna

Hi, @piranna ! Thank you for the update! We will take a look at the run you provided (as well as the workflow) and see if we can pinpoint the problem :)

dusan-trickovic avatar Jul 11 '23 08:07 dusan-trickovic

You are welcome :-)

piranna avatar Jul 11 '23 08:07 piranna

Hello, @piranna ! I apologize for waiting, I've been doing some additional repro steps in the meantime. I just wanted to check in with you again to see if you were still experiencing issues with package registries? In addition, have you tried using separate jobs for publishing? If so, did it help with the issue? If it didn't, I suppose the update will help me search for any possible alternate solutions at the very least.

Once again, I apologize for the late response and thank you very much for your cooperation and updates :)

dusan-trickovic avatar Aug 16 '23 09:08 dusan-trickovic

Yes, issue still happens, and using several jobs solved It, but it's a waste of resources because will need to download the project and dependencias a generate the package múltiple times, instead of just doing an extra upload to the second registry.

piranna avatar Aug 16 '23 10:08 piranna

@piranna Thank you for the update. I'm glad it worked by using separate jobs, but I also understand it's not the most optimal approach either. I will look into some more efficient solutions for the problem, consult with the team about it and let you know about the potential solutions we find.

dusan-trickovic avatar Aug 16 '23 13:08 dusan-trickovic

You are welcome. I think the solution is just a matter of reset state, It looks mostly like a bug for an untested corner case, probably can be fixed in one morning.

piranna avatar Aug 16 '23 13:08 piranna

Hi, I don't know if this is the correct place to put this - but I think that I'm seeing that the registry-url key is not being used at all:

name: Publish package to GitHub Packages
on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@main
      - uses: actions/setup-node@main
        with:
          node-version: 20
          cache: 'npm'
          registry-url: 'https://npm.pkg.github.com'
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

This results in the error:

npm ERR! code ENEEDAUTH
npm ERR! need auth This command requires you to be logged in to https://registry.npmjs.org/
npm ERR! need auth You need to authorize this machine using `npm adduser`

However, if I specify the registry in package.json:

  "publishConfig": {
    "registry": "https://npm.pkg.github.com"
  }

(and remove the restiry-url key from the action) then it looks to me tha the correct registry is being usedt :

npm ERR! code ENEEDAUTH
npm ERR! need auth This command requires you to be logged in to https://npm.pkg.github.com/
npm ERR! need auth You need to authorize this machine using `npm adduser`

zachsa avatar Sep 28 '23 07:09 zachsa

@zachsa that's a different error, you should open a new issue. For me, registry-url is working properly, and I use it in several projects, my problem is that once I assign it a value in a job, any try to re-assign it to a different registry gets ignored.

piranna avatar Sep 28 '23 07:09 piranna

Thanks @piranna. I changed to use a node container instead of this action, and I'm configuring .npmrc explicitly

zachsa avatar Sep 28 '23 07:09 zachsa

Thanks @piranna. I changed to use a node container instead of this action, and I'm configuring .npmrc explicitly

You are welcome :-)

piranna avatar Sep 28 '23 07:09 piranna

Have you tried setting scope to your GH and NPM registry username (respectively) as input for setup-node when you're trying to set / change registries?

Changing the scope doesn't change anything.

- uses: actions/setup-node@v4
  with:
    registry-url: https://npm.pkg.github.com
    scope: "@natoboram"
- run: pnpm publish --access public --no-git-checks
  env:
    NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

- uses: actions/setup-node@v4
  with:
    registry-url: https://registry.npmjs.org
    scope: "@natoboram"
- run: pnpm publish --access public --no-git-checks
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

You can use the CLI reproduce the actions taken by actions/setup-node@v4.

- run: |
    pnpm config set @natoboram:registry 'https://npm.pkg.github.com' --location project
    pnpm config set //npm.pkg.github.com/:_authToken '${NODE_AUTH_TOKEN}' --location project
    pnpm publish --access public --no-git-checks
  env:
    NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

- run: |
    pnpm config set @natoboram:registry 'https://registry.npmjs.org' --location project
    pnpm config set //registry.npmjs.org/:_authToken '${NODE_AUTH_TOKEN}' --location project
    pnpm publish --access public --no-git-checks
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

After digging a bit more in the source code, I realized something.

https://github.com/actions/setup-node/blob/d86ebcd40b3cb50b156bfa44dd277faf38282d12/src/authutil.ts#L7-L17

The .npmrc file it's changing isn't the one in the project, it's the global one. This means its changes can be overridden by the project's .npmrc. But, more importantly, it means that if you have private packages set by your local .npmrc, then this action doesn't help you at all.

I used act to debug the action and see what happens. After setting up actions/setup-node@v4 twice, I ran cat ${{ runner.temp}}/.npmrc. This is the result:

//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
always-auth=false
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
@natoboram:registry=https://registry.npmjs.org/

So, the action works.

TL;DR: Unset the scope in your project's .npmrc during your GitHub Workflow. Make sure to do it after pnpm install.

pnpm config delete @natoboram:registry --location project

NatoBoram avatar Jan 06 '24 21:01 NatoBoram