The first user to log into a private installation of CircleCI. Administrators have the ability to add and remove users.
A container is a running instance of an image.
Contexts provide a mechanism for securing and sharing environment variables across projects. The environment variables are defined as name/value pairs and are injected at runtime. After a context has been created, you can use the context key in the workflows section of a project
.circleci/config.yml file to give any job(s) access to the environment variables associated with the context.
Docker layer caching
The CircleCI Docker Layer Caching feature allows builds to reuse Docker image layers from previous builds. Image layers are stored in separate volumes in the cloud, and are not shared between projects. Layers may only be used by builds from the same project. For additional information about how the secure environment is created, see the Docker Layer Caching and Running Docker Commands documents.
Environment variables store customer data that is used by a project. Only project administrators and owners are allowed to view or modify environment variables. The values are transmitted using secure protocols, for example, HTTPS and SSH, encrypted at rest, and hashed/salted to prevent CircleCI employees from viewing them.
Executors define the underlying technology to run a job. Can be either
docker to run your job inside a Docker container with a specified image, or
machine to run your job inside a full virtual machine.
An image is a packaged system that includes instructions for creating a running container. The primary container is defined by the first image listed in a
.circleci/config.yml file. This is where commands are executed for jobs, using the Docker or machine executor. Visit the CircleCI Developer Hub to see available convenience and machine images.
All the containers being run by an executor for the current job.
Jobs are collections of steps, which run commands/scripts as required. Each job must declare an executor that is either docker, machine, windows, or macos.
Orbs are reusable snippets of code that help automate repeated processes, accelerate project setup, and make it easy to integrate with third-party tools. Visit the Orbs Registry on the CircleCI Developer Hub to search for orbs to help simplify your config.
The owner of the team’s VCS organization.
A CircleCI 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 are defined in your project '.circleci/config.yml.' file. Pipelines are not available on CircleCI server v2.x.
The first image listed in
.circleci/config.yml. This is where commands are executed for jobs using the Docker executor.
The user who adds a repository in the VCS to CircleCI as a project.
A CircleCI project shares the name of the code repository for which it automates workflows, tests, and deployment. It is visible on the Projects page of the CircleCI web app and must be added with the Set Up Project button. After a project is added, it is possible to configure settings, contexts, environment variables, and team members who may follow the project. Following a project enables you to subscribe to email notifications for the project’s build status, and adds the project to your CircleCI dashboard.
A feature that enables building, running, and pushing images to Docker registries from within a Docker executor job. Visit the Runner Docker Commands page to learn more.
A configuration option for specifying compute resource sizing for a job. Also used as a label to identify a pool of self-hosted runners and to configure a job to run on a self-hosted runner from that pool. Read more on the resource class overview page.
A step is a collection of executable commands. Visit the Sample Configuration page to learn more.
An individual user within an organization. A CircleCI user is anyone who can log in to the CircleCI platform with a username and password. Users must be added to a VCS organization to view or follow associated CircleCI projects. Users may not view project data that is stored in environment variables.
Workflows define a list of jobs and their run order. It is possible to run jobs concurrently, sequentially, on a schedule, or with a manual gate using an approval job.
A workspace is a workflows-aware storage mechanism. A workspace stores data unique to the job, which may be needed in downstream jobs.
Help make this document better
This guide, as well as the rest of our docs, are open source and available on GitHub. We welcome your contributions.
- Suggest an edit to this page (please read the contributing guide first).
- To report a problem in the documentation, or to submit feedback and comments, please open an issue on GitHub.
- CircleCI is always seeking ways to improve your experience with our platform. If you would like to share feedback, please join our research community.
Our support engineers are available to help with service issues, billing, or account related questions, and can help troubleshoot build configurations. Contact our support engineers by opening a ticket.
You can also visit our support site to find support articles, community forums, and training resources.
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.