Open swells opened 2 months ago
Just posting here too, autorest is currently in maintanaince mode and we don't have time to commit. Using private registry with authentication is also often tied to being locked from installing dependencies after the install stage(which breaks the JIT install that autorest does)
The current recommendation for this is to setup a package.json with the autorest dependencies in it
{
"name": "my-autorest-private-setup",
"devDependencies": {
"@autorest/core": "latest",
"@autorest/modelerfour": "latest",
"@autorest/csharp": "latest"
}
}
npm ci
And tell autorest where to find the local versions
autorest --version "$PWD/node_modules/@autorest/core" --use "$PWD/node_modules/@autorest/modelerfour" --use "$PWD/node_modules/@autorest/csharp"
Thanks @timotheeguerin for getting back to me. Where can I find out what the suggested alternative to autorest is, I don't see it here in github
I will try your suggestion above also.
Before filling a bug
Describe the bug
On these OneBranch compliant CI/CD pipelines we must use a private internal authenticated npm registry and fails tiring to acquire autorest-core's version during bootstrapping.
Expected behavior
autorest should support this as a typical use-case and use
.npmrc
on private authenticated npm registries .Here are the pipeline steps:
network isolation
Npm Authenticate via ADO
.npmrc
Set env and run autorest
Failure on getting azure-core version
Additional context
I think what is happening is after setting the env
autorest_registry
autorest'ss use ofpacote
manifest fetch to get the azure-core version fails since it can not properly authenticate:There is no way to deal with the _auth scopes from .npmrc and
pacote.manifest
. This is my speculation anyhow since this is difficult to debug this in CI pipelines.