diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/administration/audit_event_streaming.md | 68 | ||||
| -rw-r--r-- | doc/ci/yaml/index.md | 58 | ||||
| -rw-r--r-- | doc/user/project/code_owners.md | 25 | ||||
| -rw-r--r-- | doc/user/project/integrations/harbor.md | 50 |
4 files changed, 184 insertions, 17 deletions
diff --git a/doc/administration/audit_event_streaming.md b/doc/administration/audit_event_streaming.md index 817f22debbc..95501367c90 100644 --- a/doc/administration/audit_event_streaming.md +++ b/doc/administration/audit_event_streaming.md @@ -113,7 +113,7 @@ When the last destination is successfully deleted, event streaming is disabled f > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336411) in GitLab 14.9. -Users with at least the Owner role for a group can delete event streaming destinations. +Users with at least the Owner role for a group can delete event streaming destinations: 1. On the top bar, select **Menu > Groups** and find your group. 1. On the left sidebar, select **Security & Compliance > Audit events**. @@ -199,12 +199,11 @@ Users with at least the Owner role for a group can add event streaming destinati 20 headers per endpoint. 1. After all headers have been filled out, select **Add** to add the new endpoint. -Event streaming is enabled if: +### Updating custom HTTP headers -- No warning is shown. -- The added endpoint is displayed in the UI. +Add custom HTTP headers with the API or GitLab UI. -### Updating custom HTTP headers +#### Use the API > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361964) in GitLab 15.2. @@ -218,8 +217,40 @@ mutation { } ``` +#### Use the GitLab UI + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91986) in GitLab 15.3 [with a flag](feature_flags.md) named `custom_headers_streaming_audit_events_ui`. Disabled by default. + +FLAG: +On self-managed GitLab, by default the UI for this feature is not available. To make it available per group, ask an administrator to +[enable the feature flag](../administration/feature_flags.md) named `custom_headers_streaming_audit_events_ui`. On GitLab.com, the UI for this feature is +not available. The UI for this feature is not ready for production use. + +Users with at least the Owner role for a group can add event streaming destinations and custom HTTP headers for it: + +1. On the top bar, select **Menu > Groups** and find your group. +1. On the left sidebar, select **Security & Compliance > Audit events**. +1. On the main area, select **Streams** tab. +1. Select **{pencil}** at the right side of an item. +1. Locate the **Custom HTTP headers** table. +1. Locate the header that you wish to update. +1. In the **Header** column, you can change the header's name. +1. In the **Value** column, you can change the header's value. +1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the **Active** checkbox, see the + [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/361925). +1. Select **Save** to update the endpoint. + +Event streaming is updated if: + +- The returned `errors` object is empty. +- The API responds with `200 OK`. + ### Deleting custom HTTP headers +Deleting custom HTTP headers with the API or GitLab UI. + +#### Use the API + Group owners can remove a HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID by [listing all the custom headers](#list-all-custom-headers) on the group. @@ -233,6 +264,31 @@ mutation { The header is deleted if the returned `errors` object is empty. +#### Use the GitLab UI + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91986) in GitLab 15.3 [with a flag](feature_flags.md) named `custom_headers_streaming_audit_events_ui`. Disabled by default. + +FLAG: +On self-managed GitLab, by default the UI for this feature is not available. To make it available per group, ask an administrator to +[enable the feature flag](../administration/feature_flags.md) named `custom_headers_streaming_audit_events_ui`. On GitLab.com, the UI for this feature is +not available. The UI for this feature is not ready for production use. + +Users with at least the Owner role for a group can delete event streaming destinations: + +1. On the top bar, select **Menu > Groups** and find your group. +1. On the left sidebar, select **Security & Compliance > Audit events**. +1. On the main area, select **Streams** tab. +1. Select **{pencil}** at the right side of an item. +1. Locate the **Custom HTTP headers** table. +1. Locate the header that you wish to remove. +1. Select **{remove}** at the right side of the header. +1. Select **Save** to update the endpoint. + +Event streaming is updated if: + +- The returned `errors` object is empty. +- The API responds with `200 OK`. + ### List all custom headers List all custom HTTP headers with the API or GitLab UI. @@ -276,8 +332,6 @@ Users with at least the Owner role for a group can add event streaming destinati 1. On the left sidebar, select **Security & Compliance > Audit events**. 1. On the main area, select **Streams** tab. 1. Select **{pencil}** at the right side of an item. -1. A read-only view of the items custom headers is shown. To track progress on adding editing functionality, see the [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/361925). -1. Select **Cancel** to close the read-only view. ## Verify event authenticity diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md index a9384d71eba..a9c584e1347 100644 --- a/doc/ci/yaml/index.md +++ b/doc/ci/yaml/index.md @@ -3251,6 +3251,64 @@ docker build: - [Jobs or pipelines can run unexpectedly when using `rules: changes`](../jobs/job_control.md#jobs-or-pipelines-run-unexpectedly-when-using-changes). +##### `rules:changes:paths` + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90171) in GitLab 15.2. + +`rules:changes:paths` is an alias for `rules:changes`. + +**Keyword type**: Job keyword. You can use it only as part of a job. + +**Possible inputs**: + +- An array of file paths. + +**Example of `rules:changes:paths`**: + +```yaml +docker build: + script: docker build -t my-image:$CI_COMMIT_REF_SLUG . + rules: + - if: $CI_PIPELINE_SOURCE == "merge_request_event" + changes: + paths: + - Dockerfile +``` + +In this example, the `docker build` job is only included when the `Dockerfile` has changed +and the pipeline source is a merge request event. + +##### `rules:changes:compare_to` + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/293645) in GitLab 15.3 [with a flag](../../administration/feature_flags.md) named `ci_rules_changes_compare`. Disabled by default. + +Use `rules:changes:compare_to` to specify which ref to compare against for changes to the files +listed under [`rules:changes:paths`](#ruleschangespaths). + +**Keyword type**: Job keyword. You can use it only as part of a job, and it must be combined with `rules:changes:paths`. + +**Possible inputs**: + +- A branch name, like `main`, `branch1`, or `refs/heads/branch1`. +- A tag name, like `tag1` or `refs/tags/tag1`. +- A commit SHA, like `2fg31ga14b`. + +**Example of `rules:changes:compare_to`**: + +```yaml +docker build: + script: docker build -t my-image:$CI_COMMIT_REF_SLUG . + rules: + - if: $CI_PIPELINE_SOURCE == "merge_request_event" + changes: + paths: + - Dockerfile + compare_to: 'refs/heads/branch1' +``` + +In this example, the `docker build` job is only included when the `Dockerfile` has changed +relative to `refs/heads/branch1` and the pipeline source is a merge request event. + #### `rules:exists` > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24021) in GitLab 12.4. diff --git a/doc/user/project/code_owners.md b/doc/user/project/code_owners.md index adea5dad7b8..8dd6860adbd 100644 --- a/doc/user/project/code_owners.md +++ b/doc/user/project/code_owners.md @@ -59,19 +59,26 @@ Next steps: > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53182) in GitLab 12.1. > - Group and subgroup hierarchy support was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32432) in GitLab 13.0. -You can use members of groups and subgroups as Code Owners for a project. - -For example, if you have these groups: +You can use members of groups and subgroups as Code Owners for projects: + +```mermaid +graph TD + A[Parent group X] -->|owns| B[Project A] + A -->|contains| C[Subgroup Y] + C -->|owns| D[Project B] + A-. inherits ownership .-> D +``` -- **Group X** (`group-x`) with **Project A** in it. -- **Subgroup Y** (`group-x/subgroup-y`), which belongs to **Group X**, with **Project B** in it. +In this example: -The eligible Code Owners: +- **Parent group X** (`group-x`) owns **Project A**. +- **Parent group X** also contains a subgroup, **Subgroup Y**. (`group-x/subgroup-y`) +- **Subgroup Y** owns **Project B**. -- For **Project A** are the members of **Group X** only, because **Project A** doesn't belong to **Subgroup Y**. -- For **Project B** are the members of both **Group X** and **Subgroup Y**. +The eligible Code Owners are: - +- **Project A**: the members of **Group X** only, because **Project A** doesn't belong to **Subgroup Y**. +- **Project B**: the members of both **Group X** and **Subgroup Y**. You can [invite](members/share_project_with_groups.md) **Subgroup Y** to **Project A** so that their members also become eligible Code Owners. diff --git a/doc/user/project/integrations/harbor.md b/doc/user/project/integrations/harbor.md index 1319c9e74cd..da35f0dc226 100644 --- a/doc/user/project/integrations/harbor.md +++ b/doc/user/project/integrations/harbor.md @@ -39,7 +39,7 @@ GitLab supports integrating Harbor projects at the group or project level. Compl After the Harbor integration is activated: -- The global variables `$HARBOR_USERNAME`, `$HARBOR_PASSWORD`, `$HARBOR_URL`, and `$HARBOR_PROJECT` are created for CI/CD use. +- The global variables `$HARBOR_USERNAME`, `$HARBOR_HOST`, `$HARBOR_OCI`, `$HARBOR_PASSWORD`, `$HARBOR_URL`, and `$HARBOR_PROJECT` are created for CI/CD use. - The project-level integration settings override the group-level integration settings. ## Secure your requests to the Harbor APIs @@ -50,3 +50,51 @@ the `username:password` combination. The following are suggestions for safe use: - Use TLS on the Harbor APIs you connect to. - Follow the principle of least privilege (for access on Harbor) with your credentials. - Have a rotation policy on your credentials. + +## Examples of Harbor variables in CI/CD + +### Push a Docker image with kaniko + +For more information, see [Use kaniko to build Docker images](../../../ci/docker/using_kaniko.md). + +```yaml +docker: + stage: docker + image: + name: gcr.io/kaniko-project/executor:debug + entrypoint: [''] + script: + - mkdir -p /kaniko/.docker + - echo "{\"auths\":{\"${HARBOR_HOST}\":{\"auth\":\"$(echo -n ${HARBOR_USERNAME}:${HARBOR_PASSWORD} | base64)\"}}}" > /kaniko/.docker/config.json + - >- + /kaniko/executor + --context "${CI_PROJECT_DIR}" + --dockerfile "${CI_PROJECT_DIR}/Dockerfile" + --destination "${HARBOR_HOST}/${HARBOR_PROJECT}/${CI_PROJECT_NAME}:${CI_COMMIT_TAG}" + rules: + - if: $CI_COMMIT_TAG +``` + +### Push a Helm chart with an OCI registry + +Helm supports OCI registries by default. OCI is supported in [Harbor 2.0](https://github.com/goharbor/harbor/releases/tag/v2.0.0) and later. +Read more about OCI in Helm's [blog](https://helm.sh/blog/storing-charts-in-oci/) and [documentation](https://helm.sh/docs/topics/registries/#enabling-oci-support). + +```yaml +helm: + stage: helm + image: + name: dtzar/helm-kubectl:latest + entrypoint: [''] + variables: + # Enable OCI support (not required since Helm v3.8.0) + HELM_EXPERIMENTAL_OCI: 1 + script: + # Log in to the Helm registry + - helm registry login "${HARBOR_URL}" -u "${HARBOR_USERNAME}" -p "${HARBOR_PASSWORD}" + # Package your Helm chart, which is in the `test` directory + - helm package test + # Your helm chart is created with <chart name>-<chart release>.tgz + # You can push all building charts to your Harbor repository + - helm push test-*.tgz ${HARBOR_OCI}/${HARBOR_PROJECT} +``` |