re: Configuring Circle CI 2.0 for a Real Rails Application VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION
 

Hi there,

Thanks for this, it looks like you're using the webpacker gem to install yarn here so that might introduce some differences. Perhaps webpacker shields you from temporary issues when installing yarn from their install script? It could also be that your parallelism is lower than ours as we would typically see most containers work but sometimes 1-4 of them might not install yarn correctly.

The problem we were having is actually installing yarn, not caching the dependencies post install.

You're right in that you don't typically need an up-to-date yarn BUT without caching yarn's executables we would have seen the same issue of it sometimes not installing.

We are not using webpacker (yet) so I'm unsure if the protections you're receiving installing yarn are a lower parallelism or webpacker itself providing some protections (which would totally make sense).

Please let me know if I'm missing something as I could just update our config and the articles for future humans :)

 

Using webpacker indeed but the gem itself does not manage the installation of yarn (its actually a prerequisite: github.com/rails/webpacker#prerequ...)

The core difference I wanted to point out is this

dependencies:
  override:
    - yarn

I cannot explain why this works, but yeah, installs yarn without issues.

Also, yeah, parallelism is 1 and docker image is "circleci/ruby:2.5-node"

I'd be interested in trying this in the future though I really, really think that it would not fix the problem we had whereby when yarn is installed from a remote script the remote script would return invalid content or a 4x/5x error.

This dependencies key was part of Circle 1.0 and we actually used it there, but under Circle 2.0 the dependencies key is not documented as far as I can see (circleci.com/docs/2.0/configuratio...).

The image you're using will have yarn pre-installed (circleci.com/docs/2.0/yarn/) and because you're not checking its version I could see that your configuration might not even install yarn but use the image's pre-installed version which would circumvent completely the issue we had to fix.

My thoughts on why you would not have experienced the issue we did was because you're not installing yarn but using the image's version.

code of conduct - report abuse