intro

Before trying to use GitLab runner (shell) in anger, I wanted to peek under the hood – it’ll make things easier later.

I’ll stash more information here if it looks useful.

Docs:

• built in docs at gitlab.example.com/help/ci/quick_start/README
• https://docs.gitlab.com/ee/ci/

One of a number of posts on GitLab CI, see the gitlab-runner tag.

.gitlab-ci.yml

This is the basis for gitlab ci, and by default it goes in the root of the repository.

As of 9.4, it can be moved and renamed, which is nice: one less file littering the root of the repo.

• Within the repository, navigate to settings || CI / CD
• Find Custom CI config path.
• Pick your designed folder and filename.

If you add a file via the GUI, you can take a shortcut and add a template

• From new file, select .gitlab-ci.yml from the templates list.
• Select from the list of languages etc. what you’re developing.
• There’s not one for puppet, so no shortcut to had there.

environment variables and context

I started with the following CI definition to take a look around

before_script:
  - /usr/bin/echo 'before script'
  - /usr/bin/env | /usr/bin/sort
  - /usr/bin/pwd
  - /usr/bin/ls -al

after_script:
  - /usr/bin/echo 'after script'
  - /usr/bin/env | /usr/bin/sort
  - /usr/bin/pwd
  - /usr/bin/ls -al

test1:
  stage: test
  script:
    - /usr/bin/echo 'test1'
    - /usr/bin/env | /usr/bin/sort
    - /usr/bin/pwd
    - /usr/bin/ls -al

• this results in a pipeline with a single ‘box’ called test1; this is the job name
• A directory structure is created: /home/gitlab-runner/builds/XCHrAuVS/0/puppet/control-repo
• puppet/control-repo are the group and repository name; and that’s where the git repo is cloned (initially) and fetched (by default) for each run.

# git branch
* (detached from a32a6a6)
# git branch --remote -v
  origin/development       dbf4e5c (commit message)
  origin/gitlabrunner2     a32a6a6 WIP: ci
  origin/production        eeb6160 (commit message)
# git commit --oneline
a32a6a6 WIP: ci
96dcb2c WIP: ci
af15796 WIP: ci
[..]

• There’s quite a lot of environment variables available; such as commit information:

CI_COMMIT_SHA=a32a6a6d0982c052275ff7824bbfad125ce5e953
CI_COMMIT_BEFORE_SHA=96dcb2c709bc2d493128c9a9b0c573fb78f7afab
CI_COMMIT_MESSAGE=WIP: ci
CI_COMMIT_TITLE=WIP: ci
CI_COMMIT_DESCRIPTION=

• .. context ..

CI_BUILDS_DIR=/home/gitlab-runner/builds
CI_CONFIG_PATH=ci/definition.yml
CI_JOB_NAME=test1
CI_JOB_STAGE=test
CI_PROJECT_DIR=/home/gitlab-runner/builds/XCHrAuVS/0/puppet/control-repo
CI_SERVER_VERSION=11.10.3
CI_SERVER_VERSION_MAJOR=11
CI_SERVER_VERSION_MINOR=10
CI_SERVER_VERSION_PATCH=3
GITLAB_USER_EMAIL=john.smith@example.com
GITLAB_USER_ID=2
GITLAB_USER_LOGIN=john

• and other shell variables which help describe the situation..

HOME=/home/gitlab-runner
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/puppetlabs/bin:/home/gitlab-runner/.local/bin:/home/gitlab-runner/bin
USER=gitlab-runner
PWD=/home/gitlab-runner/builds/XCHrAuVS/0/puppet/control-repo
OLDPWD=/home/gitlab-runner

• The runner switches to the account before running all aspects of the pipeline.
• Running something as root would require sudo rules; eg: installing dependencies in before_script.