yarn not found in node:alpine

[beldur]

I'm using the node:alpine image in a gitlab-ci build.
Since a few minutes ago I get the following error in gitlab-ci:

$ yarn config set cache-folder .yarn
/bin/sh: eval: line 50: yarn: not found
ERROR: Job failed: exit code 127

My .gitlab-ci.yaml:

build:
  image: node:alpine
  stage: build
  script:
    - yarn config set cache-folder .yarn
    - yarn
    - yarn build

[mmcgarr]

I'm seeing the same in circleci

Step 6/9 : RUN yarn
 ---> Running in a8731d6619d5
/bin/sh: yarn: not found
The command '/bin/sh -c yarn' returned a non-zero code: 127

[rtorino]

I'm experiencing the same issue.

[Scukerman]

Same here.
Need to revert ae26d21.

[thrawny]

Same for the normal node:9.8.0

~ » docker run -it --rm node:9.8.0 sh  
# yarn
sh: 1: yarn: not found

[fabriciocolombo]

Same here with node:carbon

[nicolas-duvauchel]

This was caused by this commit: ae26d21

Given the way the symlink is done mkdir -p /opt/yarn should have been deleted

[mmcgarr]

node:9.7-alpine image seems unaffected

[SimenB]

@PeterDaveHello @chorrell

[tredston]

Seems to affect all supported tags except chakracore.

[michalpiekarski]

The problem is with mkdir -p /opt/yarn (related to missing /opt directory see #648).
The correct command should be mkdir -p /opt.

[cecton]

latest is affected I think:

The link /usr/local/bin/yarn is broken, it targets /opt/yarn/bin/yarn which doesn't exist. But /opt/yarn/yarn-v1.5.1 exists.

root@5706d42db0c6:/# ls /usr/local/
CHANGELOG.md  LICENSE  README.md  bin  etc  games  include  lib  man  sbin  share  src
root@5706d42db0c6:/# ls /usr/local/bin
node  nodejs  npm  npx  yarn  yarnpkg
root@5706d42db0c6:/# /usr/local/bin/yarn
bash: /usr/local/bin/yarn: No such file or directory
root@5706d42db0c6:/# ls /usr/local/bin
node  nodejs  npm  npx  yarn  yarnpkg
root@5706d42db0c6:/# stat /usr/local/bin/yarn
  File: '/usr/local/bin/yarn' -> '/opt/yarn/bin/yarn'
  Size: 18              Blocks: 0          IO Block: 4096   symbolic link
Device: 31h/49d Inode: 62          Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-03-16 10:19:06.000000000 +0000
Modify: 2018-03-16 10:19:06.000000000 +0000
Change: 2018-03-16 11:13:53.243600600 +0000
 Birth: -
root@5706d42db0c6:/# /usr/local/bin/yarn
bash: /usr/local/bin/yarn: No such file or directory
root@5706d42db0c6:/# /usr/local/bin/n
node    nodejs  npm     npx
root@5706d42db0c6:/# /usr/local/bin/yarn
bash: /usr/local/bin/yarn: No such file or directory
root@5706d42db0c6:/# /opt/yarn/bin/yarn
bash: /opt/yarn/bin/yarn: No such file or directory
root@5706d42db0c6:/# ls /opt/yarn
yarn-v1.5.1
root@5706d42db0c6:/# ls /opt/yarn/yarn-v1.5.1
LICENSE  README.md  bin  lib  package.json
root@5706d42db0c6:/# ls /opt/yarn/yarn-v1.5.1

[lingz]

Broke our CI as well this morning!

[SimenB]

Should #639, #647 and #648 all be reverted, or can someone send a new PR fixing it?

[elboletaire]

Same here, with every version of node. We've already tried carbon and latest. Both fail with the yarn command.

[SimenB]

This affects 9.8.0, 9.8, 9, latest, 8.10.0, 8.10, 8, carbon, 6.13.1, 6.13, 6, boron, 4.8.7, 4.8, 4, argon and all variants (alpine, slim, onbuild, wheezy, stretch)

[cecton]

@SimenB I volunteer to make a PR. I will remove the mkdir -p and replace by a symlink where the yarn has been decompressed.

[SimenB]

@cecton thanks!

[pesho]

I will be able to fix that in several hours. If anyone can take care of it earlier, please do.

[SimenB]

I asked for a revert in docker-library/official-images#4131, but I think they are all on the west coast of the US, so probably asleep.

[ghindle]

Adding the following to my Dockerfile as a temporary fix helped. Remember YMMV!
RUN mkdir -p /opt/yarn/bin && ln -s /opt/yarn/yarn-v1.5.1/bin/yarn /opt/yarn/bin/yarn

[cecton]

Close to finish....

[chorrell]

It's ok, I have a branch with the required changes. Will PR it in a minute. Will test locally as well.

[cecton]

@chorrell @SimenB please have a look ^_^ I put so much effort into it, I would be glad to contribute to the project.

[florentchauveau]

The image node:9.7-alpine can be used as a workaround until this is fixed.

[ojab]

As @SimenB already written, image id is immutable identifier of the docker image, i. e. instead of

$ docker pull node:9.8.0-alpine
9.8.0-alpine: Pulling from library/node
Digest: sha256:1fbcd77d0eb2af765d24ae4758b5a94b0d55c6002a15a4431d55795a449ebd3d
Status: Image is up to date for node:9.8.0-alpine

you should use

$ docker pull node@sha256:1fbcd77d0eb2af765d24ae4758b5a94b0d55c6002a15a4431d55795a449ebd3d

[LaurentGoderre]

There's a good reason for tags not being immutable. One of the main benefit of Docker is that you inherit security fixes to underlying images. Sure there's a chance that a change to the base image might break a build but it's a trade-off that I personally gladly take to get the security benefits.

[robinclaes]

Happening to our builds too...!

[oyvindwe]

@ojab as I wrote in my first comment, I am perfectly aware how to lock down a version. However, I find the use of “tag” misleading. In version control systems, a tag usually points to a given revision or commit (possibly on a specific branch). When a “tag” is updated, it is more like a VCS branch. The main problem with using the digest notation is that you don’t immediately see which tag it originated from.

Other repositories as Maven, NPM, Yum, etc., contain versioned artifacts. I do not see why Docker should not.

[oyvindwe]

@LaurentGoderre There exist syntaxes for specifying that you want the latest version (at some level) for semver. But providing people the possibility to easily lock down the version would be nice. You never know when even a security patch breaks your production system.

[LaurentGoderre]

We are staying consistent with the other docker official images. Maybe there will be a solution to this issue in the future (in the form of a lockfile or something)

[Shahor]

Hey guys,

thanks for the quick fix <3

That being said we continue having the problem when building our images :(
Is there something peculiar that should be done to get back to work properly?

[SimenB]

You need to wait for the image to be published. It's currently being built

[oyvindwe]

@LaurentGoderre consistency is a good thing. :) Repeatable builds provides even better consistency. My comment is not limited to the node image. Where is the right place to raise this issue?

[CalebKing3]

I'm happy we were not the only one experiencing this issue 😅 , reverting to a earlier tag was our solution but kudos to the community on this form for providing suggestions.

[cecton]

I'm happy we were not the only one experiencing this issue 😅 , reverting to a earlier tag was our solution but kudos to the community on this form for providing suggestions.

I think the whole world ended up here when they realized their builds were not passing lol!

[djbingham]

The fix seems to have made its way through the system. I've just had a GitLab CI build pass using the node:alpine image.

[danielwhatmuff]

@SimenB @LaurentGoderre - PR with changes to prevent this sort of thing happening again - #658

[rarkins]

I wrote up a blog post to explain how/why this happened, why it's not completely unexpected and can happen again, and what you can do to protect against it in future: https://renovateapp.com/blog/docker-mutable-tags

In summary:

1. Docker tags can change at any time. They are mutable and that is by design, not fault
2. Even a Docker tag that looks like semver (e.g. node:8.10.0) still has the properties of a tag and can be changed/updated at any time, like happened here
3. There are valid reasons for the image a tag points to to be changed (such as refactoring the Dockerfile or a security patch to the base), so it's not a good idea to insist that a tag that looks like a semver should never be changed
4. The only way to ensure your build is reproducible/consistent is to use Docker digests as the identifier instead of the tag
5. You can conveniently still include a Docker tag in the digest for human readability, e.g. node:8.10.0-alpine@sha256:a55d3e87802b2a8464b3bfc1f8c3c409f89e9b70a31f1dccce70bd146501f1a0
6. If you were using digests for your node base images instead of tags, you not only wouldn't have "accidentally" upgraded to the new broken image in the first place, and even if you had updated on purpose then you could have immediately rolled back the digest in your Dockerfile once you discovered the break, instead of waiting hours
7. Beyond that, these digests are a little "developer-unfriendly" to update by hand, but open source tools to automate it exist

[cecton]

I believe there is a much simpler solution: if you use Docker for your work, host your own registry and update the images when you need to.

[oyvindwe]

@cecton no build time Internet is good for private projects, but not open source development. Also, it does not solve the problems with not having a repeatable build when debugging.

[oyvindwe]

That should read: “no build time Internet dependencies”

[cecton]

Yes actually, you made a good point... I was more thinking about professional projects.

[jwineman]

Fixed by adding

RUN apk add --no-cache --virtual .build-deps \
    ca-certificates \
    wget \
    tar && \
    cd /usr/local/bin && \
    wget https://yarnpkg.com/latest.tar.gz && \
    tar zvxf latest.tar.gz && \
    ln -s /usr/local/bin/dist/bin/yarn.js /usr/local/bin/yarn.js && \
    apk del .build-deps

from https://hub.docker.com/r/jfyne/node-alpine-yarn/dockerfile to my Dockerfile.

[jstorm31]

For me the issue was in using singlequotes in Dockerfile CMD command

CMD ['yarn', 'start'] // Wrong
CMD ["yarn", "start"] // Correct