Configuring the CI pipeline

CircleCI is configured by a single YAML file with a standard name and location, that is, <root directory>/.circleci/config.yaml:

version: 2
jobs:
  build:
    docker:
    - image: circleci/golang:1.11
    - image: circleci/postgres:9.6-alpine
      environment: # environment variables for primary container
        POSTGRES_USER: postgres
    working_directory: /go/src/github.com/the-gigi/delinkcious
    steps:
    - checkout
    - run:
        name: Get all dependencies
        command: |
          go get -v ./...
          go get -u github.com/onsi/ginkgo/ginkgo
          go get -u github.com/onsi/gomega/...
    - run:
        name: Test everything
        command: ginkgo -r -race -failFast -progress
    - setup_remote_docker:
        docker_layer_caching: true
    - run:
        name: build and push Docker images
        shell: /bin/bash
        command: |
          chmod +x ./build.sh
          ./build.sh

Let's break it apart and understand what's going on. The first part specifies the build job, and below that are the necessary Docker images (golang and postgres) and their environment. Then, we have the working directory, where the build commands should be executed:

version: 2
jobs:
 build:
 docker:
 - image: circleci/golang:1.11
 - image: circleci/postgres:9.6-alpine
      environment: # environment variables for primary container
        POSTGRES_USER: postgres
    working_directory: /go/src/github.com/the-gigi/delinkcious

The next part is the build steps. The first step is just checkout. In the CircleCI UI, I associated the project with the Delinkcious GitHub repository so that it knows where to checkout from. If the repository is not public, then you'll need to provide an access token, too. The second step is a run command that gets all the Go dependencies of Delinkcious:

steps:
- checkout
- run:
    name: Get all dependencies
    command: |
      go get -v ./...
      go get -u github.com/onsi/ginkgo/ginkgo
      go get -u github.com/onsi/gomega/...

Once we have all the dependencies, we can run the tests. I am using the ginkgo test framework in this case:

- run:
    name: Test everything
    command: ginkgo -r -race -failFast -progress

The next section is where it builds and pushes the Docker images. Since it requires access to the Docker daemon, it needs special setup via the setup_remote_docker step. The docker_layer_caching option is used to make everything more efficient and faster by reusing previous layers. The actual build out and push is handled by the build.sh script, which we will look at in the next section. Note that I made sure it's executable via chmod +x:

- setup_remote_docker:
    docker_layer_caching: true
- run:
    name: build and push Docker images
    shell: /bin/bash
    command: |
      chmod +x ./build.sh
      ./build.sh

I'm just scratching the surface here. There is much more to CircleCI, with orbs for reusable configuration, workflows, triggers, and artifacts.