GitLab CI/CD

Setting a variable to the contents of a file in GitLab CI/CD

I have recently been spending some time overhauling my projects' deployment processes, and wanted to simplify how images are determined without having to set versions in multiple locations. Keep it DRY, right!

When working locally, I'm using Vite as a build tool to compile all of my front-end CSS and JS assets. For this process, the version of Node that's used is set in an .nvmrc file that's committed to each repo.

I need to run this same job in each my deployment pipelines, which uses an official Node image to run the same commands:

npm install && vite build

However, I wanted to make sure that the Node image being used matched the same version I am running locally, which I was easily able to do by setting a variable in my .gitlab-ci.yml file:

variables:
  NODE_IMAGE: node:16.19.0

The downside is that now I'm maintaining that Node version in two different places, so if I update it for the one I have to remember to update it for the other. In my search for a solution I happened upon a Stackoverflow post for how to set a variable via a bash command, which in turn led me to a GitLab issue to enable this feature.

After speaking with a colleague (and good mentor and friend), I took another look at accomplishing this in a completely separate job that runs during a prior stage to where the variable is actually needed.

So now, in a prepare stage that runs before any of the others I can grab the contents of that .nvmrc file and (along with the node: prefix) set its value to a variable in the script step, which is then saved to an .env file that's passed along to later jobs using artifacts:reports:dotenv.

"prepare":
  stage: prepare
  artifacts:
    when: always
    expire_in: 1 week
  reports:
    dotenv: vars.env
  script:
    - echo "NODE_IMAGE=node:$(cat .nvmrc)" > vars.env

Now that I have that value, I can easily use it when setting the image keyword of the actual build step in that later stage:

"build: js":
  image: $NODE_IMAGE
  stage: build
  artifacts: ...

I'd love to know if this helps anyone else having the same issue, so leave a comment below and let me know!

You May Also Like

Configuring a Cloudflare R2 Bucket and Worker For Public Access
Cloudflare R2 Workers

Configuring a Cloudflare R2 Bucket and Worker for Public Access

I recently published a plugin to integrate Cloudflare R2 with Craft CMS. After having a chance to utilize this on a few more projects after its release, I wanted to put together a guide to streamline this process for future use cases. Hopefully this will help out any others out there looking to setup R2 on their Cloudflare accounts, as most of this won't be specific to Craft CMS.

Learn More
Securing a Site With a Cloudflare Client Certificate and mTLS
Cloudflare Security

Securing a Site With a Cloudflare Client Certificate and mTLS

When a website required limited access, I needed a way to lock it down to specific physical devices. I couldn't rely on IP addresses which might change regularly, and while a strong password requirement might be sufficient I wanted something a little more secure. Not to mention that it shouldn't be crawled by any search engines either. The solution was a Cloudflare client certificate and mTLS firewall rule.

Learn More