npm package: @semkodev/test-ci
Description: test the ci
Author: Vitaliy Semko
Latest version: 0.0.23

# Test-CI (Work in Progress!)

**SemkoDev CI / Release documentation**

- [Test-CI (Work in Progress!)](#test-ci-work-in-progress)
  - [Introduction](#introduction)
  - [Setting up a CI (NPM)](#setting-up-a-ci-npm)
    - [package.json & Git](#packagejson-git)
    - [Docker](#docker)
    - [gitlab-ci.yml](#gitlab-ciyml)
  - [Releasing an NPM package](#releasing-an-npm-package)

## Introduction

The CI process is based within GitLab Ci/Pipelines infrastructure. Each job within the pipeline requires a [Runner](https://docs.gitlab.com/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](https://semver.org/) 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": "git@gitlab.com:semkodev/test-ci.git",
  "author": "Vitaliy Semko <wit@semkodev.com>",
  "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](https://docs.docker.com/engine/reference/builder/).

### 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](https://docs.gitlab.com/ee/ci/yaml/README.html).

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 ~/.npmrc`you 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](https://docs.gitlab.com/ee/ci/variables/).
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.