You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Background on how github vs gitlab work
3
+
globs:
4
+
---
5
+
6
+
Pipelines supports both GitHub and GitLab.
7
+
8
+
GitLab does not yet support account factory.
9
+
GitLab does not yet support the same level of customization as GitHub
10
+
GitLab requires one machine user with just one token and does not have a gitlab app.
11
+
## GitLab Setup Requirements
12
+
13
+
1. **Gruntwork Management Portal**: An active account is required
14
+
2. **GitLab Group Access**:
15
+
- Customers must provide Gruntwork with their GitLab group information
16
+
- Gruntwork will authorize access for the specified groups
17
+
18
+
> Important: Please contact Gruntwork support to initiate the GitLab group authorization process.
19
+
20
+
<IMPORTANT>
21
+
Whenever presenting information that diverges between github and gitlab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say ".... pull/merge requests..." and not need full <Tabs>.
Copy file name to clipboardExpand all lines: docs/2.0/docs/pipelines/architecture/actions.md
+5-2
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Pipelines Actions
2
2
3
-
When a user opens a pull request, Pipelines runs a set of operations as a Github Action Workflow in response to the proposed [infrastructure changes](/2.0/docs/pipelines/concepts/overview/#infrastructure-change). We call these operations _pipelines actions_. Gruntwork Pipelines supports the following pipelines actions:
3
+
When a user opens a pull request, Pipelines runs a set of operations as a CI Workflow in response to the proposed [infrastructure changes](/2.0/docs/pipelines/concepts/overview/#infrastructure-change). We call these operations _pipelines actions_. Gruntwork Pipelines supports the following pipelines actions:
4
4
5
5
## Terragrunt plan
6
6
@@ -12,7 +12,10 @@ When a pull request is merged, Pipelines will automatically execute either `terr
12
12
13
13
## Skipping runs
14
14
15
-
Sometimes you find it necessary to make a change without going through the full pipelines process. This can be accomplished using GitHub's built in method for skipping workflow runs [by adding [skip ci] to your commit message](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/skipping-workflow-runs).
15
+
Sometimes you find it necessary to make a change without going through the full pipelines process. This can be accomplished using built-in CI skip mechanisms:
16
+
17
+
-**GitHub**: Add `[skip ci]` to your commit or pull request message as described in the [GitHub documentation](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/skipping-workflow-runs)
18
+
-**GitLab**: Add `[skip ci]` to your commit or merge request message as described in the [GitLab documentation](https://docs.gitlab.com/ee/ci/pipelines/index.html#skip-a-pipeline)
Copy file name to clipboardExpand all lines: docs/2.0/docs/pipelines/architecture/audit-logs.md
+21-17
Original file line number
Diff line number
Diff line change
@@ -1,35 +1,39 @@
1
1
# Audit Logs
2
2
3
-
Gruntwork Pipelines provides an audit log that records which GitHub user performed specific operations in your AWS accounts as a result of a [Pipelines Action](/2.0/docs/pipelines/architecture/actions.md).
3
+
Gruntwork Pipelines provides an audit log that records which user performed specific operations in your AWS accounts as a result of a [Pipelines Action](/2.0/docs/pipelines/architecture/actions.md).
4
4
5
-
Accessing AWS environments from a CI/CD system often involves assuming temporary credentials using [OpenID Connect (OIDC)](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). Shared credentials can complicate tracking who performed specific actions in AWS accounts. Gruntwork Pipelines addresses this challenge by using [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) with a naming convention that includes context from the triggering Pipelines Action in GitHub. This approach associates every API operation performed by Pipelines with a GitHub username and a specific pull request or branch, enabling your security team to efficiently investigate access-related issues and analyze individual user actions.
5
+
Accessing AWS environments from a CI/CD system often involves assuming temporary credentials using OpenID Connect (OIDC). For platform-specific documentation, see:
Shared credentials can complicate tracking who performed specific actions in AWS accounts. Gruntwork Pipelines addresses this challenge by using [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) with a naming convention that includes context from the triggering Pipelines Action. This approach associates every API operation performed by Pipelines with a username and a specific pull request or branch, enabling your security team to efficiently investigate access-related issues and analyze individual user actions.
6
10
7
11
## How it works
8
12
9
-
Gruntwork Pipelines creates an audit log that tracks which user performed what action in which AWS account. It does this by setting the [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session name to include the initiating GitHub username, the Pipelines name, and the pull request or branch that triggered the action. Logging is handled through [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), where session names appear in the `User name` field, making it easy to identify which user performed an action. For information on locating logs, see [where you can find logs](#where-you-can-find-logs) and [querying data](#querying-data).
13
+
Gruntwork Pipelines creates an audit log that tracks which user performed what action in which AWS account. It does this by setting the [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session name to include the initiating username, the Pipelines name, and the merge request/pull request or branch that triggered the action. Logging is handled through [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), where session names appear in the `User name` field, making it easy to identify which user performed an action. For information on locating logs, see [where you can find logs](#where-you-can-find-logs) and [querying data](#querying-data).
10
14
11
15
### What gets logged
12
16
13
-
Logs are generated for all operations performed by Gruntwork Pipelines across every AWS account. These logs leverage [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session names to clearly label sessions with the GitHub username that requested the change and the associated pull request or branch.
17
+
Logs are generated for all operations performed by Gruntwork Pipelines across every AWS account. These logs leverage [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session names to clearly label sessions with the username that requested the change and the associated merge request/pull request or branch.
14
18
15
-
Each CloudTrail event linked to API calls from Pipelines [Actions](/2.0/docs/pipelines/architecture/actions.md) includes the session name in the `userIdentity` field. For example, if the GitHub user `SomeUserInYourOrg` initiated the 123rd pull request in your repository, the `userIdentity` field in a corresponding CloudTrail event would provide details such as the following.
19
+
Each CloudTrail event linked to API calls from Pipelines [Actions](/2.0/docs/pipelines/architecture/actions.md) includes the session name in the `userIdentity` field. For example, if the user `SomeUserInYourOrg` initiated the 123rd request in your repository, the `userIdentity` field in a corresponding CloudTrail event would provide details such as the following.
@@ -45,23 +49,23 @@ Each CloudTrail event linked to API calls from Pipelines [Actions](/2.0/docs/pip
45
49
}
46
50
```
47
51
48
-
Due to the 64-character limit for STS session names, the originating repository is not included in the session name. To identify the originating repository, you can search through repositories for commits matching the user and branch/PR-number combination or contact the GitHub user directly.
52
+
Due to the 64-character limit for STS session names, the originating repository is not included in the session name. To identify the originating repository, you can search through repositories for commits matching the user and request number combination or contact the user directly.
49
53
50
54
By combining this data with a [query service](#querying-data), you can analyze the usage patterns of Gruntwork Pipelines in your AWS accounts using CloudTrail logs.
51
55
52
56
### Who gets logged
53
57
54
-
Pipelines employs a naming scheme that integrates the GitHub user who triggered the Pipelines [Action](/2.0/docs/pipelines/architecture/actions.md) along with the pull request or branch that initiated the action. The AWS STS session name is formatted as follows:
Pipelines employs a naming scheme that integrates the user who triggered the Pipelines [Action](/2.0/docs/pipelines/architecture/actions.md) along with the request or branch that initiated the action. The AWS STS session name is formatted as follows:
When Pipelines runs in response to a pull request event (opened, updated, or reopened), the session name includes the user who made the most recent commit on the branch and the pull request number assigned by GitHub. For instance:
59
-
- If the user `SomeUserInYourOrg` created pull request number `123`, the session name would be:
61
+
#### For merge request/pull request events
62
+
When Pipelines runs in response to a request event (opened, updated, or reopened), the session name includes the user who made the most recent commit on the branch and the request number. For instance:
63
+
- If the user `SomeUserInYourOrg` created request number `123`, the session name would be:
60
64
`SomeUserInYourOrg-via-GWPipelines@PR-123`.
61
65
62
-
#### For merged pull requests
63
-
When Pipelines runs after a pull request is merged, the session name reflects the user who performed the merge (e.g., clicked the `merge` button) and the deploy branch name (e.g., `main`). For example:
64
-
- If the user `SomeUserInYourOrg` merged a pull request to the branch `main`, the session name would be:
66
+
#### For merged requests
67
+
When Pipelines runs after a request is merged, the session name reflects the user who performed the merge and the deploy branch name (e.g., `main`). For example:
68
+
- If the user `SomeUserInYourOrg` merged a request to the branch `main`, the session name would be:
Copy file name to clipboardExpand all lines: docs/2.0/docs/pipelines/architecture/ci-workflows.md
+32-3
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,33 @@
1
-
# GitHub Workflows
1
+
# CI Workflows
2
2
3
-
Pipelines integrates with your repositories through GitHub Workflows, leveraging [Reusable Workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) from Gruntwork's [pipelines-workflows](https://github.com/gruntwork-io/pipelines-workflows) repository. The workflows in your repositories rely on Gruntwork workflows through the uses clause within a job. This is structured as follows:
3
+
Pipelines integrates with your repositories through GitHub/GitLab Workflows, leveraging [GitHub Reusable Workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) and [GitLab Shared Components](https://docs.gitlab.com/ee/ci/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:
Gruntwork follows [Semantic Versioning](https://semver.org/) 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.
14
29
15
-
When referencing a workflow, the version is specified in the `uses` clause. For example: `pipelines-root.yml@v3`. Using the major version, like 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.
30
+
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.
16
31
17
32
## Modifying workflows
18
33
@@ -22,13 +37,17 @@ If you [fork the Gruntwork Workflows](https://docs.gruntwork.io/2.0/docs/pipelin
22
37
23
38
## Workflow dependencies
24
39
40
+
<Tabs>
41
+
<TabItem value="GitHub" label="GitHub">
42
+
25
43
The `pipelines-workflows` repository includes the following reusable workflows:
26
44
27
45
- `pipelines-drift-detection.yml`- Used for [Pipelines Drift Detection](/2.0/docs/pipelines/concepts/drift-detection) in all repositories with Drift Detection installed.
28
46
- `pipelines-root.yml`- The core Pipelines workflow for the `infrastructure-live-root` repository, providing core plan/apply functionality and account vending.
29
47
- `pipelines-unlock.yml`- Used to manually unlock state files in all repositories.
30
48
- `pipelines.yml`- The core Pipelines workflow for `infrastructure-live-access-control` and delegated repositories, supporting plan/apply operations.
31
49
50
+
32
51
In your repositories, the following workflows are typically present:
33
52
34
53
#### infrastructure-live-root
@@ -49,3 +68,13 @@ In your repositories, the following workflows are typically present:
49
68
- `pipelines-unlock.yml`- Uses the Gruntwork `pipelines-unlock.yml` workflow.
50
69
- `pipelines.yml`- Uses `pipelines.yml`.
51
70
71
+
72
+
</TabItem>
73
+
<TabItem value="GitLab" label="GitLab">
74
+
75
+
Your `.gitlab-ci.yml` file will include the following workflow:
76
+
77
+
- `GruntworkPipelines`- The core Pipelines workflow for your repository.
Copy file name to clipboardExpand all lines: docs/2.0/docs/pipelines/architecture/components.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ The executor receives a pipeline action and an infrastructure change as input an
12
12
13
13
## Execution flow
14
14
15
-
Pipelines begins with an event in GitHub, such as the creation, update, or reopening of a pull request, or a push to `main` (e.g., merging a pull request). The orchestrator determines the set of infrastructure changes (`infra-change set`) and selects the appropriate action for each change. For every change in the set, the executor performs the necessary action and logs the results in GitHub, attaching them to the pull request that triggered the workflow.
15
+
Pipelines begins with an event in GitHub/GitLab, such as the creation, update, or reopening of a merge request/pull request, or a push to `main` (e.g., merging a pull request). The orchestrator determines the set of infrastructure changes (`infra-change set`) and selects the appropriate action for each change. For every change in the set, the executor performs the necessary action and logs the results in GitHub/GitLab, attaching them to the merge request/pull request that triggered the workflow.
Copy file name to clipboardExpand all lines: docs/2.0/docs/pipelines/architecture/index.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
# Architecture
2
2
3
3
Gruntwork Pipelines is designed to provide flexibility, enabling you to utilize the components you need to manage your infrastructure in a way that aligns with your organization's requirements.
4
-
4
+
5
5
6
6
Understanding the components and their structure will help you use Pipelines and associated Infrastructure as Code (IaC) effectively.
7
7
@@ -15,8 +15,8 @@ All other infrastructure managed with Gruntwork software ultimately depends on r
15
15
16
16
### Workflows
17
17
18
-
-**Account Factory:** Provides an API for interacting with the Gruntwork Account Factory. It uses a [repository dispatch](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#repository_dispatch) to create AWS account requests.
19
-
18
+
-**Account Factory:**(GitHub only) Provides an API for interacting with the Gruntwork Account Factory. It uses a [repository dispatch](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#repository_dispatch) to create AWS account requests.
19
+
20
20
This workflow uses a [repository dispatch](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#repository_dispatch) to create a standard AWS account creation request in the repository.
21
21
22
22
The workflow payload is a JSON object, which can be constructed using the sample HTML file included in the repository. This file can be customized for organizational needs, such as adding tagging fields or additional context.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?v=4&size=40){kind=avatar}
0 commit comments