New images fail to install private modules with yarn

Encountering a pretty serious regression that has broken all our CI builds with no clear workaround (other then updating all builds to install and use a local fixed version of yarn, which is far from ideal) . 😱 😓 On boron image.

Looks like the node docker images were all updated around 5 hours ago which is about when I started seeing this issue. Basically yarn will not install any private node modules even with a valid token in ~/.npmrc (gives 404 errors). I think the new images updated from yarn v0.22.0 to v0.23.2. Using 0.23.2 locally with npmrc without issue.

The recent image update was for yarn v0.23.2. Maybe a regression or bug in yarn?

Yea, I cross posted to their issue tracker (see above). My obviously bias opinion is to revert to 0.22.0 in the LTS images since this is a critical breaking issue.

@razor-x

@razor-x Were you using auth tokens or basic auth urls? Auth tokens never worked for me ever. On the other hand other have reported that url auth works/worked: yarnpkg/yarn#2541 (comment)

@noherczeg

@noherczeg Been using //registry.npmjs.org/:_authToken=foo (this is what is generated by npm login. This has worked with yarn locally and on the docker builds for several months now up until yesterday.

@noherczeg

@noherczeg I've tried registry=https://${NPM_USERNAME}:${NPM_PASSWORD}@registry.yarnpkg.com as you suggested. It worked locally but not in the docker build.

@chorrell Any hope of reverting to yarn 022.0 in the boron images? Unless you or someone can verify that installing private NPM packages is possible using the new image, I would say this is a serious regression and warrants a revet until a solution can be found.

I'd like to get some input on the yarn team before we make a decision. If a new release is eminent that fixes this then we should update rather than revert back to v0.22.0.

Huh, and there's this too: yarnpkg/yarn#3138

And this: yarnpkg/yarn#3203

So I'm leaning more toward reverting back to v0.22.0

Hey @nodejs/docker, what does everyone else think?

v0.23.2 solved yarnpkg/yarn#2819, but compared to the other issues it doesn't seem as bad

Only yarnpkg/yarn#3203 remaining, right? In that case I vote on updating to v0.23.2. Yarn is already experimental and most people using it should know that. It won't become more stable unless people use it and test the latest versions.

Yarn is already experimental and most people using it should know that. It won't become more stable unless people use it and test the latest versions.

+1, this is also why I'm slightly in favor of not reverting. Although being upset is understandable when your build breaks.

It would be great if there was a clean way to not update Yarn (or NPM for that matter) in an already published tag. I.e. tags should be immutable w.r.t. the package versions included (except for updates to the base image).

Only yarnpkg/yarn#3203 remaining, right?

Yah, I think so. So wait until v0.23.3 or v0.24.x ? Whichever is the next release...

For future updates, should we stick to updating yarn only when we update node? That way someone could use a previous tagged release if they wanted to.

For future updates, should we stick to updating yarn only when we update node? That way someone could use a previous tagged release if they wanted to.

I think that would be preferable somewhat. It would not be perfect though, because when one branch updates (e.g. 7.x), update.sh will update the Yarn version in the other branches too.

Yeah, I was just thinking the same thing. At some point v7 would probably drift and have a more recent version of yarn.

A possible solution would be to invoke update.sh with only the branch(es) that actually have new version(s), e.g. ./update.sh 7.6 6.10

yeah, that would work

@chorrell

For future updates, should we stick to updating yarn only when we update node? That way someone could use a previous tagged release if they wanted to.

This would be more consistent with how each version of node is bundled with a specific version of npm.

Yarn is already experimental and most people using it should know that. It won't become more stable unless people use it and test the latest versions.

I agree, but maybe there is a balance to find. As others have suggested, having the latest yarn version for stable while for lts only updating yarn when node is updated feels less surprising in terms of what level of stability might be expected. Yarn has almost 25k stars: clearly many people are depending on it even before it's v1 'stable' release so regressions like this will no doubt affect many users. I'm not suggesting any guarantees were made by Node / Yarn here, it's just the reality of the situation.

@chorrell Is the plan still to wait for the next yarn release? Do we know this regression is fixed upstream (specifically since it seems to only affect the docker image). Would this release be expedited to fix the regression (trying to estimate a rough timeline to determine how this will effect our priorities).

I think the consensus so far is to wait for the next release.

I don't know if the issue is fixed yet in master.

We can close this right?

Yes, I think so!

…

On 7 Jul 2017, at 09:29, Simen Bekkhus ***@***.***> wrote: We can close this right? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

@Starefossen

I'm still getting this in 0.24.6; I don't think it should be closed, @Starefossen

@gvilarino

@gvilarino @Donov4n Do you have a repro? If you do yarn global add yarn to get the latest, does it work?

The problem come from the fact that yarn seem to forget the ~/.npmrcconfig when you are outside the home directory.

You can reproduce the bug like this:

$ docker run --rm -ti node:latest bash
$ echo '//my-private-npm-registry.com/:_authToken=[my-token]' > ~/.npmrc

$ cd && yarn config list 
yarn config v0.24.6
(...)
info npm config
{ '//my-private-npm-registry.com/:_authToken': '[my-token]',  # ---> OK !
  version: '0.24.6',
  loglevel: 'info' }

$ cd / && yarn config list 
yarn config v0.24.6
(...)
info npm config
{ version: '0.24.6',  # --> Not OK, where are the private registry credentials ?
  loglevel: 'info' }

That doesn't seem like an issue with the node docker image, rather with yarn. You can open up an issue with them (the behavior is the same in 0.27.5)

@SimenB

@SimenB my repro is:

FROM node:6.10.3-slim

ARG NPM_TOKEN

ENV NPM_TOKEN=$NPM_TOKEN

EXPOSE 3000

RUN npm config set //registry.npmjs.org/:_authToken=$NPM_TOKEN

RUN curl -o- -L https://yarnpkg.com/install.sh | bash -s --

WORKDIR /usr/src

COPY [".", "/usr/src/"]

CMD ["node", "index.js"]

Unless I add --version 0.22.0 to the end of the line where I install yarn, I get the following error:

<< previous docker logs>>
...
 > Successfully installed Yarn 0.27.5! Please open another terminal where the `yarn` command will now be available.
 ---> xxx
Removing intermediate container xxx
Step 7/14 : WORKDIR /usr/src
 ---> xxx
Removing intermediate container xxx
Step 8/14 : COPY package.json .snyk .npmrc yarn.lock /usr/src/
 ---> xxx
Removing intermediate container xxx
Step 9/14 : RUN $HOME/.yarn/bin/yarn install --silent --pure-lockfile --production
 ---> Running in xxx
error An unexpected error occurred: "https://registry.yarnpkg.com/@my-org%2my-private-repo: Not found".
The command '/bin/sh -c $HOME/.yarn/bin/yarn install --silent --pure-lockfile --production' returned a non-zero code: 1

Any ideas?

Navigation Menu

Repository navigation

New images fail to install private modules with yarn #386

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

New images fail to install private modules with yarn #386

Description

Activity

chorrell commented on Apr 21, 2017

razor-x commented on Apr 21, 2017

noherczeg commented on Apr 21, 2017

razor-x commented on Apr 21, 2017

razor-x commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

Starefossen commented on Apr 24, 2017

pesho commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

pesho commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

pesho commented on Apr 24, 2017

chorrell commented on Apr 24, 2017

razor-x commented on Apr 25, 2017

chorrell commented on Apr 25, 2017

SimenB commented on Jul 7, 2017

Starefossen commented on Jul 7, 2017

gvilarino commented on Jul 14, 2017

SimenB commented on Jul 15, 2017

Donov4n commented on Jul 15, 2017

SimenB commented on Jul 16, 2017

gvilarino commented on Jul 19, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions