Savita Seetaraman

Savita Seetaraman

Basic Concepts of CircleCI: Part 1

CircleCI is a continuous integration and delivery tool. The following are some basic concepts of CircleCI. Half of them shall be covered in this post. There shall be a part 2, which shall be cover the remaining concepts.

  1. configuration,
  2. steps,
  3. executors,
  4. jobs,
  5. workflows,
  6. orbs,
  7. caches,
  8. contexts.

Configuration

The configuration for CircleCI is provided through a .yaml file. The configuration file is placed in the .circleci/config.yaml. It follows the concept of configuration as code.

Steps

Steps are the smallest unit of execution in a config.yaml file. The most common step is checkout which means checking out the source code from the repository. A step could also be linux commands, in which case, these are preceded by a run: keyword.

Some of the other common keywords are:

  • save_cache,
  • restore_cache,
  • deploy,
  • store_test_results,
  • add_ssh_keys,
  • attach_workspace.

Executors

Executors are environments that are used to run separate jobs in. These could be:

  • VMs running operating systems like Linux, macOS or Windows, or
  • Docker containers.
Images can be specified for each executor. CircleCI has a list of prebuilt Docker images that can be used. The first image mentioned in the .circle/config.yaml is taken as the primary container image.

Jobs

A job is run within a separated unit like a VM or container. Some of the components of a job configuration included under a job are:

  • executors,
  • steps,
  • environment,
  • parameters.
The most common job is a build. Some of the advantages of jobs are:
  • Caching between different runs of a job persists, making it faster to test builds.
  • Artifacts persist after running a workspace

Workflows

Workflows are a collection of jobs. They contain the following keys:

  • version
  • jobs
Workflows can run multiple jobs in parallelly. These could be jobs with completely different steps, executors and images. If we want to run jobs serially, we could use the requires keyword. We could schedule jobs to run at regular intervals of time.

The remaining concepts will be covered in Part 2 of this post.