Self-Hosted CI/CD: Because You Don't Want to Pay for It

Setting up self-hosted CI/CD can be a daunting task, but trust me, it's worth it. The finished result is a system that automates your testing, building, and deployment process, saving you time and sanity. Here's an example of what the final .gitlab-ci.yml file might look like:

stages:
  - build
  - test
  - deploy
build:
  stage: build
  script:
    - npm install
    - npm run build

This snippet defines a simple pipeline with three stages: build, test, and deploy.

The Basics

To get started, you'll need to choose a self-hosted CI/CD tool like GitLab Runner or Jenkins. For this example, we'll use GitLab Runner. You'll also need a server to run it on - a Raspberry Pi or an old AWS EC2 instance will do. Here's an example of how to install GitLab Runner on Ubuntu:

sudo apt-get update
sudo apt-get install gitlab-runner

Don't forget to register the runner with your GitLab instance.

The Pipeline

The pipeline is where the magic happens. You define the stages, scripts, and environment variables in the .gitlab-ci.yml file. For example, you can use Docker to run your tests:

test:
  stage: test
  script:
    - docker run -t my-test-image npm run test

This snippet runs the tests inside a Docker container.

Common Mistake: Forgetting to Limit Resources

One common mistake is forgetting to limit the resources used by the runner. This can cause your server to run out of memory or CPU, bringing everything to a grinding halt. To avoid this, make sure to set limits on the runner:

build:
  stage: build
  script:
    - npm install
    - npm run build
  resources:
    limits:
      memory: 512M
      cpu: 1

This snippet limits the build stage to 512M of memory and 1 CPU core.

That's it. With these basics, you can set up a self-hosted CI/CD system that will save you time and sanity. Just remember to monitor your resources and update your pipeline regularly.