NPM_REGISTRY_AUTH_URL for gcloud

[W]

I'm trying to use this tool to publish my built NPM package to a private NPM artifact registry on gcloud. I can't figure out what the NPM_REGISTRY_AUTH_URL variable should be set to, not seeing it in gcloud.

https://bitbucket.org/atlassian/npm-publish/src/master/

I see this message at the top of the repositories list: all "*gcr.io" traffic is currently routed to Container Registry. Route to Artifact Registry after copying any images you need from Container Registry.

I put the gcloud artifact repo link best I could determine in that variable but it's still going to npmjs for some reason.

npm ERR! 404 Not Found - PUT https://registry.npmjs.org/project-name Not found

npm ERR! 404

npm ERR! 404 'project-name@0.1.0' is not in the npm registry.

npm ERR! 404 You should bug the author to publish it (or use the name yourself!)

npm ERR! 404

npm ERR! 404 Note that you can also install from a

npm ERR! 404 tarball, folder, http url, or git url.

[Igor Stoyanov]

@W  hi. Thanks for your question.

have you tried these examples from the README:

Publishes a package from the package1 directory to a private registry. Support authentication url environment variable in case of npm registry url host cannot be used for authentication.

script:
  - pipe: atlassian/npm-publish:0.3.2
    variables:
      NPM_TOKEN: $NPM_TOKEN
      NPM_REGISTRY_AUTH_URL: 'my-internal-registry.local/path'
      FOLDER: 'package1'

package.json file example:

{
  "name": "package",
  "version": "1.0.11",
  "description": "Description",
  "publishConfig":{"registry":"my-internal-registry.local/path/repo_name"}
}

?

Regards, Igor

[W]

I have tried this, many iterations and variations of interpretation. I got past the above problem only to face addition issues that were overlapping.

I think I might have discovered the root problem. gcloud might require the key to change every 1 hour, 12 is considered extended while npmjs keys can last a year in legacy mode. If that's the case, bitbucket pipelines isn't compatible with gcloud artifact repo. I created a service account then a service account key file that I downloaded. After that you download it local and run a base 64 command against the file to generate the NPM_TOKEN as described here.

Out of 40 pushes, I got it working once. It always works when I push from local to gcloud because I'm using an account authenticated with password and user. I have a support request put in as well.

Unless I'm doing this wrong, it seems the only solution is for pipelines to accept the key file so it can generate new tokens on each push... but I'm no expert.

Here is what the key file looks like

{
  "type": "service_account",
  "project_id": "PROJECT_ID",
  "private_key_id": "KEY_ID",
  "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
  "client_email": "SERVICE_ACCOUNT_EMAIL",
  "client_id": "CLIENT_ID",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
}

[Igor Stoyanov]

@W  seems like you used short-living token, that expired in 1 hour.
For long living tokens you should set up service account via this guide:
https://cloud.google.com/artifact-registry/docs/nodejs/authentication#auth-password

Regards, Igor

[W]

hmmm... I swear I've repeated those steps and read that page like 10 times now. But I never noticed "Service account keys are long-lived credentials."  I read this one a few times as well, which claims access tokens are good for 1 hour: https://cloud.google.com/docs/authentication/token-types#access

Maybe it's something unrelated, maybe somehow I was generating the NPM_TOKEN against my own credentials and that's the only reason it pushed the artifacts to the repo 1/25 builds.

I might repeat my steps, isolate concerns better (always a good solution).

[W]

Well, on second thought:

• "Service account keys are long-lived credentials." - i.e. the key file. if that interpretation is right it supports my theory.
• "... access tokens are good for 1 hour ... When the access token has expired, your token management code must get a new one. If you need an access token with a longer lifetime...generate an access token for a service account with a lifetime of up to 12 hours.

Only theories on the table:

• bitbucket pipeline auth instructions/settings are incompatible with gcloud artifact repo. i.e. missing functionality and testing.
• I have some phantom problem that has plagued me for a week.