CircleCi

Orbs

Executors

Define the environment in which a job will run on, allowing you to reuse a single executor definition across multiple jobs.

An executor definition has the following keys available (some of which are also available when using the job declaration):

• docker, machine, windows, or macos

• environment

• working_directory

• shell

• resource_class

Once you declare a definition of executor => you can use them in jobs in scope of declaration.

NOTE. Docker alpine tags: it’s a smaller version with the necessary minimum

version: 2.1
executors:
  my-executor:
    docker:
      - image: circleci/ruby:2.4.0

jobs:
  my-job:
    executor: my-executor
    steps:
      - run: echo outside the executor
  second-job:
    executor:
      name: my-executor
    steps:
      - run: echo outside the executor

Machine executor

version: 2
jobs:
  build:
    machine:
      image: ubuntu-1604:201903-01
      docker_layer_caching: true    # default - false

Docker executor

It is possible to specify multiple images for your job. Specify multiple images if, for example, you need to use a database for your tests or for some other required service. In a multi-image configuration job, all steps are executed in the container created by the first image listed. All containers run in a common network and every exposed port will be available on localhost from a primary container.

jobs:
  build:
    docker:
    # Primary container image where all steps run.
     - image: buildpack-deps:trusty
    # Secondary container image on common network. 
     - image: mongo:2.6.8-jessie
       command: [mongod, --smallfiles]

    working_directory: ~/

    steps:
      # command will execute in trusty container
      # and can access mongo on localhost
      - run: sleep 5 && nc -vz localhost 27017

Commands

A command defines a sequence of steps to be executed in a job, enabling you to reuse a single command definition across multiple jobs.

version: 2.1
commands:
  sayhello:
    description: "A very simple command for demonstration purposes"
    parameters:
      to:
        type: string
        default: "Hello World"
        description: "bla"
    steps:
      - checkout // just a possibility
      - restore_cache:
        - keys: 
          - //...
      - run: echo << parameters.to >>
      - run: // can be second run
      - save_cache:
        - keys: // ...
        - paths: // ...       

Jobs

With jobs, we can automate common behaviour using our commands described previously and they will be used in the workflows section of the CircleCI configuration.

jobs:
  my-job-name:
    description: >
      Uses circleci/aws-ecr to build and publish the docker images.
      Runs kubectl rollout restart deployment/NAME afterwards to refresh the latest tag on cluster.
    executor: <<parameters.executor>>

    parameters:
      executor:
        description: executor to use for this job
        type: executor
        default: default
      repo:
        description: The ecr repo to push the docker images.
        type: string
      tag:
        description: Some descr
        type: string
        default: "latest,${CIRCLE_SHA1}"
      eks_account_id:
        description: Some descr
        type: env_var_name
        default: EKS_ACCOUNT_ID

    steps:
      - aws-ecr/ecr-login-for-secondary-account
      - aws-ecr/build-and-push-image:
          attach-workspace: true
          repo: <<parameters.repo>>
          path: <<parameters.path>>
          tag: <<parameters.tag>>
          dockerfile: <<parameters.dockerfile>>
      - run:
          name: "Install tools"
          command: |
            # sudo wget -O kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.14.6/2019-08-22/bin/linux/amd64/kubectl
            sudo wget -O kubectl https://storage.googleapis.com/kubernetes-release/release/v1.15.0/bin/linux/amd64/kubectl
            sudo chmod +x ./kubectl
            sudo cp ./kubectl /bin/kubectl
            sudo apt-get install jq
      - run:
          name: Restart deployment
          command: |
            tokenResponse=$(aws sts assume-role \
            --role-arn arn:aws:iam::$<<parameters.eks_account_id>>:role/$<<parameters.role_in_target_account>> \
            --role-session-name AWSCLI-Session)