Test-CI (Work in Progress!)

SemkoDev CI / Release documentation

• Test-CI (Work in Progress!)
  • Introduction
  • Setting up a CI (NPM)
    • package.json & Git
    • Docker
    • gitlab-ci.yml
  • Releasing an NPM package

Introduction

The CI process is based within GitLab Ci/Pipelines infrastructure. Each job within the pipeline requires a Runner. Currently, the SemkoDev group has one own runner installed on AWS. To see it's state go to the group->Settings->CI->Runners.

This private project is a demo of an automatic release process. Using only git commits/pushes you can automatically trigger:

• automatic tests on all branhces that are pushed
• publish of the package on npm repo
• create a docker image and publish it on the official docker.io registry (tagged with version as well as latest)
• create a docker image and publish it on the project's GitLab registry (tagged with version as well as latest; find the images under Registry menu)

This project is an example for a CI process of an npm package. Other examples (e.g. Go) will follow.

Setting up a CI (NPM)

package.json & Git

Make sure to use a semver type version in the package.json. Also, use the semkodev scope (this is needed to publish the package under semkodev in npmjs registry). Furthermore, add a script to the package.json : "postversion": "git push --follow-tags" - it will automatially push the new version with tags (see below).

E.g.:

{
  "name": "@semkodev/test-ci",
  "version": "0.0.22",
  "description": "test the ci",
  "main": "build/testci",
  "repository": "[email protected]:semkodev/test-ci.git",
  "author": "Vitaliy Semko <[email protected]>",
  "license": "MIT",
  "scripts": {
    "build": "rm -rf ./build; mkdir ./build; cp ./src/index.js ./build/testci; chmod +x ./build/testci",
    "test": "echo 'tested'",
    "postversion": "git push --follow-tags"
  },
  "devDependencies": {}
}

Regarding git: let's use git-flow like syntax of branches (/feature, /bugfix), but keep the master branch only. The reason is that a small team doesn't need the heavy process. For continuous delivery one single integration branch is easier and more effective to work with.

Docker

It is recommended to publish all code as a docker image, so that it is easily deployable & installable in other places. Simply create a Dockerfile with all the relevant setup code. Please refer to the Docker docs.

gitlab-ci.yml

Next is a file that should be in the root of the project called: .gitlab-ci.yml . You can see an example of the contents of this file in the present project. The file describes the CI process that is triggered each time something is pushed to GitLab repository.

Please refer to the docs of the gitlab-ci.yml file format.

In the exampe .gitlab-ci.yml of this project you will see that the test-task is executed on each push. The release-tasks however are only executed when the pushed commit has been tagged with a version.

Important to note in this file are project-specific variables that you will need to set-up for your project independently:

| Variable | Meaning | Where to find it | | :------------------------: | :--------------------------------------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NPM_TOKEN | token to publish to the npmjs repo | Login to npmjs npm login (your account must have access to semkodev organization); less ~/.npmrcyou will see a token after //registry.npmjs.org/:_authToken= use it! | | DOCKER_REGISTRY_USER | docker hub user | Login details to your docker hub account (must have access to semkodev organization) | | DOCKER_REGISTRY_PASSWORD | docker hub password | Password for DOCKER_REGISTRY_USER | | DOCKER_REGISTRY_IMAGE | image name of your project at docker hub | This must be scoped within the semkodev organization. Example value: semkodev/testci |

The rest of the variables in the example YAML are either calculated or already provided to the Runner by GitLab behind the scenes. Where do we place the four variables? On the GitLab's project's page go to Settings->CI/CD->Variables. Place the variables there and you are good to go!

While you are at it, in Settings->CI/CD->General Pipeline Settings, uncheck Public pipelines to prevent outsiders to see the CI job logs and artifacts.

Releasing an NPM package

• [ ] Make sure you are on the master branch and have commited your changes
• [ ] Check the current package version with npm version
• [ ] Decide a new version, e.g. 0.0.34
• [ ] Update the CHANGELOG, if you have one
• [ ] npm version 0.0.34; Our script ("postversion": "git push --follow-tags") will automatically push the release-commit to GitLab.
• [ ] Done! The GitLab CI will test and release the package to npmjs and the DockerHub, because our commit has a semver version tag.