fix: add configuring NPM

[BeksOmega]

Description

Maybe fix the "Publish key not found" error we're getting when running the action.

Based on: (some of which are internal)

• https://groups.google.com/a/google.com/g/node-team/c/-IwpBEtJWOI/m/dOou1WuXCgAJ
• https://sites.google.com/corp/google.com/node-team/publishing-npm-packages#h.p_jGg6QLAWAwDp
• https://docs.npmjs.com/using-private-packages-in-a-ci-cd-workflow#set-the-token-as-an-environment-variable-on-the-cicd-server
• https://github.com/hsubox76/firebase-js-sdk/blob/master/.github/workflows/deploy-canary.yml

[maribethb]

I think you also need to add this:

- env:
      NODE_AUTH_TOKEN: ${{ secrets.RELEASE_BACKED_NPM_TOKEN }}

to this step in order to convert the github secret into an environment variable for this command to use. based on https://docs.npmjs.com/using-private-packages-in-a-ci-cd-workflow#set-the-token-as-an-environment-variable-on-the-cicd-server

[BeksOmega]

I think the env is scoped to the specific step. So I think it needs to be in the publish step where it currently is. See also this example: https://github.com/azu/lerna-monorepo-github-actions-release/blob/master/.github/workflows/publish.yml

[maribethb]

But you aren't currently setting the environment variable NODE_AUTH_TOKEN anywhere. so you need to set that somewhere. and since you need that variable in this step I think you would need to set it in this step. but you can also set it for the whole workflow or job if we need that.

in other words from your example I don't think you are doing this line https://github.com/azu/lerna-monorepo-github-actions-release/blob/315ed6abbf54698b62fc6885b1d425d0a6259053/.github/workflows/publish.yml#L32

what you are doing with the environment in the publish step is making that secret available to use in this workflow but you're not actually using it anywhere that i can see.

[BeksOmega]

My understanding was that the environment variable doesn't actually get evaluated until the npm publish step. I don't think it would be evaluated during npm config since you don't have to call npm config (if you're using a static .npmrc file). [Edit: Although I guess if since we are using npm config then bash substitution is applied?]

This example that uses a static .npmrc sets the environment variable in the publish step. This example that double-quote echos to the .npmrc sets it in the config step and the publish step. So idk what to believe.

I'm cool moving it and trying it out.

in other words from your example I don't think you are doing this line https://github.com/azu/lerna-monorepo-github-actions-release/blob/315ed6abbf54698b62fc6885b1d425d0a6259053/.github/workflows/publish.yml#L32

I think that's an unrelated thing. The GITHUB_TOKEN is created automatically, and only necessary for doing things with github, like publishing releases. Based on the github access token docs. But again, idk what to believe anymore lol.

[maribethb]

OK, I think we were misunderstanding each other. I didn't see on line 46 that you were setting the environment at all. When you said "in the publish step" I was mistakenly looking at line 16 which would be "in the publish job" and only sets the value of "environment" not "env". So I did not see where you were setting the variable at all.

However I do think what you have now is correct. If we were using a .npmrc file, I think it would indeed read the value of the environment variable during the publish step. But I did some testing and I think when you use npm config set it reads the value right away. To test I ran these commands:

export NODE_AUTH_TOKEN=123
npm config set //wombat-dressing-room.appspot.com/:_authToken=$NODE_AUTH_TOKEN
npm config list

The output includes: //wombat-dressing-room.appspot.com/:_authToken = (protected) which isn't the most helpful, but if it were just listing the name of the environment variable, I think it would probably say that here instead of "(protected)" which implies it's a literal value. But for another test I did

export NODE_AUTH_TOKEN=123
npm config set testValue=$NODE_AUTH_TOKEN
export NODE_AUTH_TOKEN=456
npm config list

And here the output includes: testValue = "123" so at least for an arbitrary key, it seems it evaluates the environment variable immediately upon setting, rather than at read time. Of course it could behave differently for the auth token setting, but with both of these tests turning out this way I believe it would be correct to set the env variable in this step.

[maribethb]

I think this is ready to try, but since the previous publish failed after lerna tagged the releases but before actually putting the packages on npm, I think we are now in a weird state. To clear it up we have a few options

1. Run lerna publish --from-git (possibly with additional args) to go ahead and manually publish the previous versions to npm (this command will not create new tags it will just publish the ones already there)
2. Revert the commit lerna made with the tags and possibly also delete all the releases it made
3. Run a force publish (manually) which would bump all the versions again, effectively skipping the bumps that lerna made

then with either option 1 or 3 we'd make a new test change to a package to have something to publish to test this workflow.

i am leaning toward option 1 unless if you have other ideas / opinions!

[maribethb]

OK, I think we were misunderstanding each other. I didn't see on line 46 that you were setting the environment at all. When you said "in the publish step" I was mistakenly looking at line 16 which would be "in the publish job" and only sets the value of "environment" not "env". So I did not see where you were setting the variable at all.

However I do think what you have now is correct. If we were using a .npmrc file, I think it would indeed read the value of the environment variable during the publish step. But I did some testing and I think when you use npm config set it reads the value right away. To test I ran these commands:

export NODE_AUTH_TOKEN=123
npm config set //wombat-dressing-room.appspot.com/:_authToken=$NODE_AUTH_TOKEN
npm config list

The output includes: //wombat-dressing-room.appspot.com/:_authToken = (protected) which isn't the most helpful, but if it were just listing the name of the environment variable, I think it would probably say that here instead of "(protected)" which implies it's a literal value. But for another test I did

export NODE_AUTH_TOKEN=123
npm config set testValue=$NODE_AUTH_TOKEN
export NODE_AUTH_TOKEN=456
npm config list

And here the output includes: testValue = "123" so at least for an arbitrary key, it seems it evaluates the environment variable immediately upon setting, rather than at read time. Of course it could behave differently for the auth token setting, but with both of these tests turning out this way I believe it would be correct to set the env variable in this step.

[BeksOmega]

Option 1 sounds good to me! For the test we can use #1150

[BeksOmega]

I think #1122 should probably wait until we get the script to work once. Or it should be merged and a publish should be manually triggered.