Concurrency Support for Registry Caching

[JakeCooper]

Summary

If the pack command is run concurrently and registry caches are constructured, there is a racecase which occurs where both invocations will attempt to update the fs

Output

Before

file exists ERROR: failed to build: locating in registry heroku/nodejs-yarn@0.1.3: refreshing cache: initializing (<$HOME>/.pack/registry-a932275bd19c2d9e1b88fa06698fd2f5427a363d25bf87fa500691c373089381): creating registry cache: rename /tmp/registry373937049 <$HOME>/.pack/registry-a932275bd19c2d9e1b88fa06698fd2f5427a363d25bf87fa500691c373089381: file exists

This change captures and passes on that error

After

Documentation

• Should this change be documented?
  • Yes, see #___
  • No

Related

Resolves #___

[aemengo]

Thanks so much for making a contribution!

I'm a little uneasy however about validating on a naked string like that. I'd be more inclined to check if the file is already there, but the code already does that...

May I ask the use-case for running this pack command concurrently?

[JakeCooper]

Totally understand. Ideally the os package would provide enums for it's errors but I couldn't find them!

EDIT: It appears the package does export an error enum so I've updated the PR :)

We use pack to power the buildpack experience for http://railway.app/. When a user fires builds without dockerfiles, we use pack to bundle their code to docker images.

We had a user today use an older version of a buildpack which fired two builds using the same repository cache, resulting in a collision in the file system

[aemengo]

Looks good to me. I think it's up to a maintainer to give their seal of approval.

I wish you the best of luck with http://railway.app/. Looks really cool!

[JakeCooper]

Bump. Any thoughts here or things I'd need to do to get this merged?

CC @jromero

[dfreilich]

Looks great to me, and thank you for the PR! Always majorly appreciated when users of pack contribute fixes, in addition to error reports :D