build-storybook breaks on linux in CI

[irudoy]

Describe the bug

Storybook build fails on Docker container with node:12 image (in GitLab CI)
https://github.com/nodejs/docker-node/blob/41ea0562287bbf98693572c9228edc1beb7fd709/12/alpine3.12/Dockerfile

info @storybook/react v6.1.0
info 
info => Cleaning outputDir /builds/.../.storybook-out
ERR! Error: EISDIR: illegal operation on a directory, copyfile '/.../.storybook-out' -> '/root/.local/share/Trash/files/963272c4-1efa-4f38-81d7-d95364db9e0d'
ERR!  [Error: EISDIR: illegal operation on a directory, copyfile '/.../.storybook-out' -> '/root/.local/share/Trash/files/963272c4-1efa-4f38-81d7-d95364db9e0d'] {
ERR!   errno: -21,
ERR!   code: 'EISDIR',
ERR!   syscall: 'copyfile',
ERR!   path: '/.../.storybook-out',
ERR!   dest: '/root/.local/share/Trash/files/963272c4-1efa-4f38-81d7-d95364db9e0d'
ERR! }

Definitely related to this: 9d4264b and this: sindresorhus/trash#92

[fabiosantoscode]

I faced this issue as well on my Ubuntu 2020.04 desktop, with storybook 6.1.0-rc.4 (don't know if it matters).

I worked around this by building the storybook myself, then using the --storybook-build-dir option to stop chromatic from building the storybook.

[fabiosantoscode]

On this package's README:

Note: The Linux implementation is not very good and not maintained. Help welcome. If no one steps up to help maintain it, I will eventually remove Linux support.

Perhaps it shouldn't be used at all?

[shilman]

@ghengeveld @ndelangen easiest solution would just be to revert that line and remove the folder instead (with some performance hit). WDYT?

[fabiosantoscode]

If my comments seem strange, it's because I faced this while trying to get chromatic to play along with React 17 and the new _jsx thing.

I got lost in the yak shaving and commented as if it was the chromatic repo.

[leonboot]

This breaks our CI process as well. I suppose it will break a lot of Linux-based CI systems. While I appreciate protecting the user against accidental unintended and permanent removal of potentially important data, if the output dir is set to a directory that may contain data that should not be deleted, using a library that mimics the host OS' trash mechanism doesn't seem like the best approach. Maybe just fail if the output dir is a non-empty directory?

[ghengeveld]

Let's revert for now, but we may want to add a bit of a safety net because running build-storybook -o / (i.e. outputDir: "/", which get's deleted) would be pretty destructive (in theory at least, I didn't check if it actually works, for obvious reasons). Basically this was a little bomb that we defused by switching to trash.

[fabiosantoscode]

Very interesting. I now understand why the trash package is being used. However, if things are moved to the trash, doesn't that increase the disk usage each build? From what I understand it's possible to trash multiple versions of a folder with the same name.

How do other packages that output/compile things into directories deal with this?

[shilman]

Hurrah!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.1.3 containing PR #13211 that references this issue. Upgrade today to the @latest NPM tag to try it out!

npx sb upgrade

Closing this issue. Please re-open if you think there's still more to do.

[petmat]

Ran into a similar issue with Storybook 6.1.11 in Docker container node:14.15 (Running in TeamCity CI):

info @storybook/react v6.1.11
info
info => Cleaning outputDir /usr/app/stories/dist
ERR! Error: EBUSY: resource busy or locked, rmdir '/usr/app/stories/dist'
ERR!  [Error: EBUSY: resource busy or locked, rmdir '/usr/app/stories/dist'] {
ERR!   errno: -16,
ERR!   code: 'EBUSY',
ERR!   syscall: 'rmdir',
ERR!   path: '/usr/app/stories/dist'
ERR! }

Could there still be some issue with removing the directory that has not been resolved?

Builds worked fine with Storybook 6.0.27.

[russellwpatterson]

We're also experiencing this in our CI system. I believe it's due to the outputDir being a docker volume. Looks like the way these deletes happened changed in 6.1.x. I'll be submitting a PR soon for a simple fix that just empties the folder instead of removing and recreating it.