Another question is the…

Another question: is there a good guide out there about setting up a Gitlab CI pipeline with Nx & caching? I feel like my CI is way too slow (partly due to npm install and my blurry understanding of how to setup the cache)

Responses:

Are you on nx 9? or 8?

if you are on 9 then upgrade to the newest version and caching is enabled by default, you can then signup for nx-cloud and add the token and it’ll all be taken care of for you!

I’m on V9, using NX cloud already

I’m asking because I’m facing huge build times, but it’s mostly related to bad handling of node_modules caching unfortunately: https://gitlab.com/gitlab-org/gitlab-runner/issues/1797

Then your CI should be using the cache already (as long as you have your cloud auth token in your env variables)

ohhh gotcha ok

It doesn’t sound like it’s solved on Gitlab, so I’m wondering how others are dealing with it :smile:

We use Circle but our steps are essentially

1. try to restore cache based on checksum of lock file
2. If it exists go to test/build steps
3. if it doesn’t exist, then install dependencies
4. Then we use modclean to strip out hundreds of MB of unused and unnecessary files
5. save that cache using the checksum from lock file
6. persist to work space and go to test/build

Not entirely sure how different github actions are.

Sounds good; and how are your CI build/test times?

Maybe I should look into CircleCI for the time being.. :smile:

Depending on what is affected (and if the developer ran the tests/builds prior to pushing and triggering a build) it could be between 5 to 20 minutes

for non deploy flows we have 8 steps that are run, to split about apps and libaries and not over use resources, smaller apps are built on smaller resource classes to reduce our credit usage since they don’t need as much RAM to build etc.

on full deploy pipelines it can take up to a half hour even if all apps need to deploy as most of it is run in parallel.

has helped one of our clients with a GitLab+Nx setup

In terms of NX Cloud setup, there isn’t anything different for GitLab vs other CI systems.

So I guess it’s a matter of getting npm installs as fast as possible. It looks like the project I’m on takes about 1.5 minutes to do npm ci in the initialize stage, and then the node_modules/ folder is an artifact shared by subsequent jobs in the same pipeline — note, no shared global cache.

For reference, the node_modules/ for this workspace is 1.6 GB.

indeed, good point. Ok so to be sure that I understand, there’s an init job (not init script right?) that handles npm ci and stores that as an artifact and the cache: directive is not used?

Wow one and a half minutes is not long for 1.6gb. ours takes that long or longer running yarn install on circle with like 600mb of node modules

To be fair, there was another dev that did a lot of the research and set up on for GitLab. I was there are the Nx expert to help with integration on that side.

It looks like artifacts may be better than caching — perhaps it’s not uploaded the same way? Worth a try.

``` stages:

• initialize
• verify
• test
• e2e

install-deps: stage: initialize script: - npm ci only: - merge_requests artifacts: paths: - node_modules/```

On Circle it is much faster to persist the node modules to the workspace between jobs than it is to save and restore the cache between jobs.

Looks something like that

That would make sense then

That being said I am using modclean as well to strip down the node modules so the persist is faster, not sure if the persist vs save/restore scales linearly over node module size or not. I found that the save/restore cache took a huuuuge range of time depending on the time of day. sometimes it took 30 seconds sometimes it was 4 monutes.

Thanks for sharing ! I’m wondering, given that the install-deps script only runs for merge_requests. How are node modules available for other pipelines?

You can remove that part if needed. What matters is that the install runs once at the beginning of the pipeline, and the other jobs in the same pipeline can use the node_modules artifact.

This means though, if you have a PR that didn’t change dependencies, you still need to run the install since we don’t have a cache available.

Yep, I see. I’ve adapted my gitlab-ci.yml file. Unfortunately the issue remains mostly the same, the init step took like 25 minutes :smile:

My node_modules folder takes 870m for 175K files. What takes a ton of time is the execution of ngcc on postinstall (~7 minutes) (running on my NAS) and the artifact’s upload (which is roughly equivalent to the time it took with the cache before)