CI Workflows
Pipelines integrates with your repositories through GitHub/GitLab Workflows, leveraging GitHub Reusable Workflows and GitLab Shared Components from Gruntwork's repositories. The workflows in your repositories rely on Gruntwork workflows through the uses/component clause within the workflow declaration. This is structured as follows:
- GitHub
- GitLab
jobs:
GruntworkPipelines:
uses: gruntwork-io/pipelines-workflows/.github/workflows/pipelines-root.yml@v3
include:
- component: gitlab.com/gruntwork-io/pipelines-workflows/pipelines@3
Workflow versioning
Gruntwork follows Semantic Versioning for pipelines-workflows releases. New releases are tracked using git tags in the v.MAJOR.MINOR.PATCH format. A major tag, such as v.MAJOR, is also maintained and updated to point to the latest release within that major version. For example, when releasing a patch update from v3.0.1 to v3.0.2, the v3 tag will be updated to reference the newer version.
When referencing a workflow, the version is specified in the uses or component clause. For example: pipelines-root.yml@v3. Using the major version, e.g. v3, in your workflows ensures you receive the latest updates and performance enhancements. However, you can choose to pin to a specific version if needed.
Modifying workflows
Changes made to workflows in your repositories only affect the specific repository where the modification occurs. For instance, customizing the pipelines.yml workflow in your infrastructure-live-root repository will not impact workflows in other repositories, such as delegated repositories.
If you fork the Gruntwork Workflows, you can make changes that affect multiple repositories. Be sure to understand the dependencies between workflows in the pipelines-workflows repository and your repositories. The dependencies are detailed below.
Workflow dependencies
- GitHub
- GitLab
The pipelines-workflows repository includes the following reusable workflows:
pipelines-drift-detection.yml- (Enterprise only) Used for Pipelines Drift Detection in all repositories with Drift Detection installed.pipelines-root.yml- (Account Factory only) The core Pipelines workflow for theinfrastructure-live-rootrepository, providing core plan/apply functionality and account vending.pipelines-unlock.yml- (AWS only) Used to manually unlock state files in all repositories.pipelines.yml- The core Pipelines workflow forinfrastructure-live-access-controland delegated repositories, supporting plan/apply operations.
If you are using Gruntwork Account Factory, the following workflows are typically present:
infrastructure-live-root
account-factory.yml- A standalone workflow independent ofpipelines-workflows.pipelines-drift-detection.yml(Enterprise only) - Uses the Gruntworkpipelines-drift-detection.ymlworkflow.pipelines-unlock.yml- Uses the Gruntworkpipelines-unlock.ymlworkflow.pipelines.yml- Usespipelines-root.yml.
infrastructure-live-access-control
pipelines-drift-detection.yml(Enterprise only) - Uses the Gruntworkpipelines-drift-detection.ymlworkflow.pipelines-unlock.yml- Uses the Gruntworkpipelines-unlock.ymlworkflow (AWS only).pipelines.yml- Usespipelines.yml.
infrastructure-live-delegated (Vended Delegated Repositories)
pipelines-drift-detection.yml- Uses the Gruntworkpipelines-drift-detection.ymlworkflow.pipelines-unlock.yml- Uses the Gruntworkpipelines-unlock.ymlworkflow.pipelines.yml- Usespipelines.yml.
Your .gitlab-ci.yml file will include the following workflow:
GruntworkPipelines- The core Pipelines workflow for your repository.