Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!



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.

I see this message at the top of the repositories list: all "*" 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 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.


1 answer

0 votes
Igor Stoyanov
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Feb 17, 2023

@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.

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

package.json file example:

  "name": "package",
  "version": "1.0.11",
  "description": "Description",


Regards, Igor

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": "",
"token_uri": "",
"auth_provider_x509_cert_url": "",
"client_x509_cert_url": ""
Igor Stoyanov
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Feb 17, 2023

@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:


Regards, Igor

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:

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).

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.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events