The CircleCI docs are good, but there’s a lot of them and I think we only use a small subset of its functionality.
This post is just a note of some of what I learned while reviewing a CircleCI config file.
Before you read the docs I would strongly recommend reading through the Concepts page which covers in more depth most of what I’m describing here.
“Pipelines”, “Workflows”, “Jobs”, “Steps”
Pipelines are defined in CircleCI config files. A pipeline is the full set of processes you run when you trigger work on your projects. Pipelines encompass your workflows, which in turn coordinate your jobs.
Pipelines can be triggered by events (such as a Git push), schedules or the CircleAPI.
Workflows are ordered lists of jobs. You can specify that jobs run in series by saying that one job depends on another in the configuration. Jobs in a workflow can also run in parallel or on a schedule.
Jobs are collections of steps executed in order.
Steps are the individual “commands” run by a job. They are either Circle’s build in commands such as run or checkout. There is a list in the configuration reference.
Steps can also run re-usable, custom commands from Orbs.
“Cache” vs “Workspace”
These features both store files between steps – the difference is how long the files persist.
Workspaces: Each workflow has a temporary workspace associated with it. The workspace can be used to pass along unique data built during a job to other jobs in the same workflow.
These are good for saving the working directory of a build between jobs within a workflow.
Caches: Caching … reuses the data from previous jobs… After an initial job run, subsequent instances of the job run faster, as you are not redoing work.
This is used as a persistent filesystem that can store files between workflow runs. We use it to cache our npm and composer dependencies to speed up subsequent deploys.
This article covers it well if you want to read more.