Giters

geeklearningio / gl-vsts-tasks-yarn

Yarn Package Manager Visual Studio Team Services Build and Release Management extensions

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to run yarn after upgrading yarn version to 3.x in azure build pipeine

BharathiUpputella opened this issue · comments

commented

Before opening an issue please read this.

Are you reporting a bug or a feature request ?

  • Bug

Description

We are trying to run yarn command after installing yarn version 3.x using command "yarn set version 3.x". Yarn command is failing with error "The lockfile would have been modified by this install, which is explicitly forbidden."
Insert your description here

Expected behavior

But when we tried to install yarn version 2.x by using command "yarn set version berry" and then tried running yarn command to install dependencies and it worked.

Describe the expected behavior

Reproduction

Insert reproduction steps here

MANDATORY FOR BUGS: Insert debug trace

image

In order to allow us to quickly reproduce you issue please include a link to a reproduction repository

System information

VSTS or TFS:

  • VSTS
  • TFS

Agent:

  • Hosted
  • Custom

OS:
ubuntu

Yarn version:
Yarn version*

Node version:
Node version* 14.x

commented

I'm having the same issue. From what I've found, the default functionality is to add the auth token in .npmrc, but Yarn 3.x doesn't use .npmrc. The credentials need to either be stored in .yarnrc.yml in the project directory or in the user root directory.

The credentials are set up a little bit differently too. You can't just use a base64 auth token - you need to use the token as the "password" in a basicauth-like scheme, where the username is the org. That needs to be set in the .yarnrc.yml like this, where the contents within the curly braces are replaced with the final base64-encoded string.

npmAuthIdent: "{{ base64(<org>:<token>) }}"

I've looked through all of the azure library code and tried to trace the logic to figure out how it gets the token in the first place. It looks like it's getting it from some sort of secret value that may or may not be an environment variable. I'm not sure. Either way, this is a blocker for my team as well.

commented

@karlhepler I faced the same issue as you, though it was separate from the "The lockfile would have been modified by this install, which is explicitly forbidden." My workaround in #115 might be useful to you.