Gitlab CI

A couple of setups are needed to use Onboardbase in a Gitlab CI environment.

First, you must create a project on Onboardbase and set up the required environments. This guide will assume three environments: build, development, and production.

Head over to your Gitlab Project, under Settings > CICD > Variables Section

Create a new variable called ONBOARDBASE_TOKEN, and use a service token generated from here as the value

Next, on GitlabCI YAML config, use a runner that supports NodeJS or add an installation command to your before script from onboardbase.sh, that installs Onboardbase:

before_script:
  - curl -Ss https://files.onboardbase.com/install.sh | bash - && source ~/.bashrc
  - onboardbase config:set --token=$ONBOARDBASE_TOKEN --scope /

Now, create a folder called ci-scripts in your project root folder and add as many stages as required. In this guide, we would assume a build and deploy stage and two deploy environments(deploy and build).

mkdir ci-scripts
touch ./ci-scripts/{build,deploy-dev,deploy-prod}.sh // create build.sh, deploy-dev.sh, deploy-prod.sh
chmod +x ./ci-scripts/{build,deploy-dev,deploy-prod}.sh // makes the files executable
# save the below in every file
# !#/bin/bash

# printenv

# twoline to do everything above
mkdir ci-scripts
for i in ci-scripts/{build,deploy-dev,deploy-prod}.sh; do touch $i; chmod +x $i; echo -e $'!#/bin/sh\n\nprintenv' > $i; done;

# test the script
cat ci-scripts/build.sh
cat ci-script/deploy-dev.sh
cat ci-scripts/deploy-prod.sh

We need to set up the pipelines and stages. Start with a build stage.

Firstly, we set the context for the CLI by pointing the project name and environment to what we have set up on Onboardbase.

Now extend the gitlab-ci.yml with the section below:

build_project:
  stage: build
  script:
    - onboardbase config:set -scope / -p $ONBOARDBASE_PROJECT_NAME -e $ONBOARDBASE_BUILD_ENVIRONMENT
    - onboardbase run "./ci-scripts/build.sh"

This should ensure that once a new push is made to the repo, the build stage runs by running the ci-scripts/build.sh script with the right environment variables from Onboardbase.

Next, we set up the build-dev stage, which runs the build-dev.sh script when there is a change in the dev branch on Gitlab.

Extend the gitlab-ci.yml with the below yaml config.

deploy_dev:
  stage: deploy
  script:
    - onboardbase config:set -scope / -p $ONBOARDBASE_PROJECT_NAME -e $ONBOARDBASE_DEVELOPMENT_ENVIRONMENT
    - onboardbase run './ci-scripts/deploy-dev.sh'
  only:
    - dev

We would do the same thing for the production environment, only changing the script, environment, and branch name.

deploy_prod:
  stage: deploy
  script:
    - onboardbase config:set -scope / -p $ONBOARDBASE_PROJECT_NAME -e $ONBOARDBASE_PRODUCTION_ENVIRONMENT
    - onboardbase run './ci-scripts/deploy-prod.sh'
  only:
    - main

The final script would look like this:

image: centos:alpine

stages:
  - build
  - deploy

cache:
  paths:
    - node_modules/

before_script:
  - curl -Ss https://files.onboardbase.com/install.sh | bash - && source ~/.bashrc
  - onboardbase config:set --token=$ONBOARDBASE_TOKEN --scope /

build_project:
  stage: build
  script:
    - onboardbase run "./ci-scripts/build.sh" -p $BUILD_PROJECT_NAME -e $BUILD_ENVIRONMENT

deploy_dev:
  stage: deploy
  script:
    - onboardbase run './ci-scripts/deploy-dev.sh' -p $ONBOARDBASE_PROJECT_NAME -e $ONBOARDBASE_DEVELOPMENT_ENVIRONMENT
  only:
    - dev


deploy_prod:
  stage: deploy
  script:
    - onboardbase run './ci-scripts/deploy-prod.sh' -p $ONBOARDBASE_PROJECT_NAME -e $ONBOARDBASE_PRODUCTION_ENVIRONMENT
  only:
    - master

NB: You can execute commands without pulling the files to a bash script. Having the commands in the script ensures the scripts are testable outside the CI environment and more maintainable. So, the onboardbase run ./ci-scripts/deploy-prod.sh can still be onboardbase run 'printenv'