Test job fails to cache dependencies when using yarn

[circleci-public]

Test job fails to cache dependencies when using yarn

[KyleTryon]

Hello all,

@cjcolvar Thank you! We have addressed the above in the following PR: #38

Please let us know if you run into any issues in the future.

Thanks again

[cjcolvar]

@KyleTryon Worked like a charm! ✨

[KyleTryon]

Hello @cjcolvar

Are you able to resolve the issue by specifying the custom yarn.lock file using the cache_key parameter?

We have to default to one of the values. We could override the choice on yarn, and force users to use a yarn.lock file, which might be fair, or maybe we create a separate yarn-cache-key parameter.

[KyleTryon]

example: https://github.com/CircleCI-Public/circleci-demo-ruby-rails/blob/master/.circleci/config.yml#L15

Or would maybe a better example showcasing this for yarn users be the best option?

[cjcolvar]

@KyleTryon Thanks for checking in on this.

I was hoping to be able to use the test job since my use case was very simple but ended up having to write my own job in order to explicitly set cache-key in the install-packages step (see avalonmediasystem/react-iiif-media-player@1867520). I just submitted a PR which exposes the cache-key to the job's configuration for this use case. It would be nice though if there was a way for the job to detect and use which ever lock file is default for the pkg-manager so a user doesn't even need to know about setting the additional parameter.

[KyleTryon]

@KyleTryon Thanks for checking in on this.

It would be nice though if there was a way for the job to detect and use which ever lock file is default for the pkg-manager so a user doesn't even need to know about setting the additional parameter.

I think we could do this but then it would not be overrideable. We would lock it down to package-lock.json and yarn.lock respectively.

I don't believe this should cause any problems but I wonder if for some reason folks may want that control.

[cjcolvar]

I don't believe this should cause any problems but I wonder if for some reason folks may want that control.

I don't know enough of the landscape to know if that is too unlikely a scenario to worry about or not. I think either approach is an improvement over current behavior though.