DEV Community

Discussion on: Configuring Circle CI 2.0 for a Real Rails Application

Collapse
 
nunosilva800 profile image
Nuno Silva

About yarn, I never got any problems with this:

version: 2
dependencies:
  override:
    - yarn

jobs:
  build:
    steps:
      [...]
      # Restore yarn cache
      - type: cache-restore
        name: Restore yarn cache
        key: cache-yarn-{{ checksum "yarn.lock" }}

      - run:
          name: Yarn Install
          command: yarn install

      # Store yarn / webpacker cache
      - type: cache-save
        name: Store yarn cache
        key: cache-yarn-{{ checksum "yarn.lock" }}
        paths:
          - ~/.yarn-cache

You don't really need to have the very latest version of yarn.
Your yarn.lock file is usually enough to handle the dependencies, etc.

One thing that I was hoping to find here are post-build notifications.
Ideally, after a deploy step... Last time I checked the docs, it was not possible on the version 2 API

Collapse
 
ozzyaaron profile image
Aaron Todd

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 :)

Collapse
 
nunosilva800 profile image
Nuno Silva

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"

Thread Thread
 
ozzyaaron profile image
Aaron Todd

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.