-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[BUG] npm 7 + Azure Devops Artifacts #2619
Comments
We've dug a bit further on this... the URI to our registry is:
However there is an alternate URI some of our developers are using that resolves to the same endpoint:
EDIT: This second URI is part of a URI move MS are in the process of rolling out (although it's been around for a while now) - https://docs.microsoft.com/en-us/azure/devops/release-notes/2018/sep-10-azure-devops-launch#administration This results in the As I said before, this wasn't an issue for v6, but does seem to have impacted v7 for the installs in the pipeline to fail. |
Might be related: #2508 |
Thank you for reporting this, I thought I was going crazy when our builds suddenly started to fail. edit: upgraded to 7.5.4, same issue |
@BobBuildingCode i agree it’s an issue with v7. However from investigation enabling ‘dev.azure.com’ as the sole url in settings also seems to have an impact. But that might also mean you repointing your feed to that endpoint as it uses different urls. You can get them in feed settings. |
Update to the issue - There definitely seems to be something up with how v7 is handling the urls. Our situation is a developer has his registry set to use In the build pipeline we use the I can replicate this locally, and have managed to find that if I add this to my npmrc it solves the issue depending on which registry my npmrc is pointing to...
I have tested this in v6 and it does not require this setting for either scenario and works as expected. |
what other values should npm be using besides the ones in the lockfile? |
Yes you're right, it should use them - by 'some reason' I guess I mean it displays them in the verbose output when they fail. When it works (by adding always-auth) they end up at a different url 'https://fv1vsblobprodsu6weus82.blob.core.windows.net' - no idea why... When I add the 'alway-auth' it works, even though always-auth is also set globally - maybe it's being ignored? |
@ljharb Is my understanding correct that if a registry is defined (either by an .npmrc file or cli flag) then NPM should transparently attempt to resolve packages from that registry rather than the urls in the package-lock.json file when installing? |
@leepowelldev that is my understanding as well. |
@ljharb That is what I think isn't happening - I don't think npm is respecting a defined registry (either by an .npmrc file or cli flag) and instead falling back to using the resolved url in the package-lock.json file (which may be a completely different registry with differnt authentication). |
I got it working by removing always-auth and regenerating access tokens. Steps takenThis is on a Windows 10 machine, there are probably more ways to achieve the same:
NotesThe majority of the steps seems unnecessary, but it did not work by just removing Detailed output for comparison after taking the steps above
|
Yes, I believe the trick here for you was enabling the 'Switch existing organizations to use the new domain name URL' - effectively using a single url through Azure which the generated access token is valid for and transparently redirects. Sadly we can't switch to the single url for legacy reasons right now and NPM seems to be failing when telling it which registry URL to use. |
If anyone from the NPM team is interested in seeing this in action, I've set up a demo Azure account with pipelines setup to show it succeeding with v6, failing with v7, and failing with v7 pointing npm to the public registry. Happy to share credentials, just email me at lee@leepowell.dev |
This is the raw log when attempting to use the public registry upon install:
And this is the package-lock.json file:
As you can see in the |
Seems the issue also exists in Yarn: We're seeing similar issues in other teams now where for local development they're using a private internal registry (which upstreams to public npm), whose URL ends up in the lock file, and then when they come to deploy via CI are unable to specify a publicly available registry to install from. They are either having to delete the lock file (less than ideal) or run a pre-build script that modifies the urls in the lock file (again not ideal). |
We have an issue very similar to this bug report #2183, which has apparently been fixed. However we're seeing the issue in the latest version of v7 (and previous versions).
Current Behavior:
We have a number of Azure Devops build pipelines which make use of the built in Artifacts (registry) feature. All build pipelines are already authenticated to retrieve these packages, and it works fine with v6.
The build pipelines utilise the
npm task
(https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/npm?view=azure-devops) to perform the install. However the install task is failing with 401 errors.An odd thing I have noticed in the logs is that the pipeline runs a
npm config list
and the results are different between using v6 and v7:v6
v7
As you can see, v7 shows this in the config
//***.pkgs.visualstudio.com/_packaging/***-***-***-***-***/npm/registry/:_authToken = (protected)
, which v6 doesn't. And the install error log is around an invalid auth token. So not sure if this has something to do with it.Install log Error:
Expected Behavior:
The install process should work as v6 does.
Environment:
Azure Devops
npm task
The text was updated successfully, but these errors were encountered: