Workflows concepts

Here are some concepts and terms to know when building, testing, or deploying your code with workflows in CodeCatalyst.

Workflows

A workflow is an automated procedure that describes how to build, test, and deploy your code as part of a continuous integration and continuous delivery (CI/CD) system. A workflow defines a series of steps, or actions, to take during a workflow run. A workflow also defines the events, or triggers, that cause the workflow to start. To set up a workflow, you create a workflow definition file using the CodeCatalyst console's visual or YAML editor.

Tip

For a quick look at how you might use workflows in a project, create a project with a blueprint. Each blueprint deploys a functioning workflow that you can review, run, and experiment with.

For more information about workflows, see Working with workflows.

Workflow definition files

A workflow definition file is a YAML file that describes your workflow. The file is stored in a ~/.codecatalyst/workflows/ folder in the root of your source repository. The file can have a .yml or .yaml extension.

For more information about the workflow definition file, see Workflow definition reference.

Actions

An action is the main building block of a workflow, and defines a logical unit of work to perform during a workflow run. Typically, a workflow includes multiple actions that run sequentially or in parallel depending on how you've configured them.

For more information about actions, see Working with actions.

Action groups

An action group contains one or more actions. Grouping actions into action groups helps you keep your workflow organized, and also allows you to configure dependencies between different groups.

For more information about action groups, see Grouping actions into action groups.

Artifacts

An artifact is the output of a workflow action, and typically consists of a folder or archive of files. Artifacts are important because they allow you to share files and information between actions.

For more information about artifacts, see Working with artifacts.

Compute

Compute refers to the computing engine (the CPU, memory, and operating system) managed and maintained by CodeCatalyst to run workflow actions.

For more information about compute, see Working with compute.

Environments

An environment, not to be confused with a Dev Environment, is where code is deployed to. It usually contains an instance of a running application along with its associated infrastructure. You can give your environment a name such as development, test, staging, or production. Any deployments generated by CodeCatalyst to an environment will appear on the Environments page. To set up an environment, you give it a name, such as my-production-environment, and then associate it with your AWS account.

In addition to displaying deployment information, an environment also serves as the mechanism through which to assign AWS IAM roles to workflow actions.

For more information about environments, see Working with environments.

Gates

A gate is a workflow component that you can use to prevent a workflow run from proceeding unless certain conditions are met. An example of a gate is the Approval gate where users must submit an approval in the CodeCatalyst console before the workflow run is allowed to continue.

You can add gates between sequences of actions in a workflow, or before the first action (which runs immediately after the Source downloads). You can also add gates after the last action, if you have a need to do so.

For more information about gates, see Working with gates.

Reports

A report contains details about tests that occur during a workflow run. You can create reports such as a test report, a code coverage report, a software composition analysis report, and a static analysis report. You can use a report to help troubleshoot a problem during a workflow. If you have many reports from multiple workflows, you can use your reports to view trends and failure rates to help you optimize your applications and deployment configurations.

For more information about reports, see Test report types.

Runs

A run is a single iteration of a workflow. During a run, CodeCatalyst performs the actions defined in the workflow configuration file and outputs the associated logs, artifacts, and variables.

For more information about runs, see Working with runs.

Sources

A source, also called an input source, is a source repository that a workflow action needs access to in order to carry out its tasks. For example, a workflow action might need to access a source to obtain unit tests and run them against your application source files.

For more information about sources, see Working with sources.

Variables

A variable is a key-value pair that contains information that you can reference in your CodeCatalyst workflow.

For more information about variables, see Working with variables.

Workflow triggers

A workflow trigger, or simply a trigger, allows you to start a workflow run automatically when certain events occur, like a code push. You might want to configure triggers to free your software developers from having to start workflow runs manually through the CodeCatalyst console.

You can use three types of trigger:

• Push – A code push trigger causes a workflow run to start whenever a commit is pushed.

• Pull request – A pull request trigger causes a workflow run to start whenever a pull request is either created, revised, or closed.

• Schedule – A schedule trigger causes a workflow run to start on a schedule that you define. Consider using a schedule trigger to run nightly builds of your software so that the latest build is ready for your software developers to work on the next morning.

You can use push, pull request, and schedule triggers alone or in combination in the same workflow.

For more information about triggers, see Working with triggers.