diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/api/remote_mirrors.md | 31 | ||||
| -rw-r--r-- | doc/architecture/blueprints/ci_pipeline_components/index.md | 13 | ||||
| -rw-r--r-- | doc/ci/pipelines/downstream_pipelines.md | 5 | ||||
| -rw-r--r-- | doc/ci/testing/unit_test_report_examples.md | 3 | ||||
| -rw-r--r-- | doc/development/sidekiq/worker_attributes.md | 2 |
5 files changed, 25 insertions, 29 deletions
diff --git a/doc/api/remote_mirrors.md b/doc/api/remote_mirrors.md index 1013ffb49fb..bd59aa64e45 100644 --- a/doc/api/remote_mirrors.md +++ b/doc/api/remote_mirrors.md @@ -8,15 +8,15 @@ type: reference, api # Project remote mirrors API **(FREE)** [Push mirrors](../user/project/repository/mirror/push.md) -defined on a project's repository settings are called "remote mirrors", and the -state of these mirrors can be queried and modified via the remote mirror API -outlined below. +defined on a project's repository settings are called "remote mirrors". You +can query and modify the state of these mirrors with the remote mirror API. -## List a project's remote mirrors +For security reasons, the `url` attribute in the API response is always scrubbed of username +and password information. -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/38121) in GitLab 12.9. +## List a project's remote mirrors -Returns an Array of remote mirrors and their statuses: +Returns an array of remote mirrors and their statuses: ```plaintext GET /projects/:id/remote_mirrors @@ -47,10 +47,6 @@ Example response: ] ``` -NOTE: -For security reasons, the `url` attribute is always scrubbed of username -and password information. - ## Get a single project's remote mirror > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82770) in GitLab 14.10. @@ -84,19 +80,14 @@ Example response: } ``` -NOTE: -For security reasons, the `url` attribute is always scrubbed of username -and password information. - ## Create a pull mirror Learn how to [configure a pull mirror](projects.md#configure-pull-mirroring-for-a-project) using the Projects API. ## Create a push mirror -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24189) in GitLab 12.9. - -Push mirroring is disabled by default. You can enable it by including the optional parameter `enabled` when creating it: +Push mirroring is disabled by default. To enable it, include the optional parameter +`enabled` when you create the mirror: ```plaintext POST /projects/:id/remote_mirrors @@ -106,8 +97,8 @@ POST /projects/:id/remote_mirrors | :---------- | :----- | :--------- | :------------ | | `url` | String | yes | The target URL to which the repository is mirrored. | | `enabled` | Boolean | no | Determines if the mirror is enabled. | -| `only_protected_branches` | Boolean | no | Determines if only protected branches are mirrored. | | `keep_divergent_refs` | Boolean | no | Determines if divergent refs are skipped. | +| `only_protected_branches` | Boolean | no | Determines if only protected branches are mirrored. | Example request: @@ -135,8 +126,6 @@ Example response: ## Update a remote mirror's attributes -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/38121) in GitLab 12.9. - Toggle a remote mirror on or off, or change which types of branches are mirrored: @@ -148,8 +137,8 @@ PUT /projects/:id/remote_mirrors/:mirror_id | :---------- | :----- | :--------- | :------------ | | `mirror_id` | Integer | yes | The remote mirror ID. | | `enabled` | Boolean | no | Determines if the mirror is enabled. | -| `only_protected_branches` | Boolean | no | Determines if only protected branches are mirrored. | | `keep_divergent_refs` | Boolean | no | Determines if divergent refs are skipped. | +| `only_protected_branches` | Boolean | no | Determines if only protected branches are mirrored. | Example request: diff --git a/doc/architecture/blueprints/ci_pipeline_components/index.md b/doc/architecture/blueprints/ci_pipeline_components/index.md index 115f6909d2d..6e5ab8040ae 100644 --- a/doc/architecture/blueprints/ci_pipeline_components/index.md +++ b/doc/architecture/blueprints/ci_pipeline_components/index.md @@ -115,21 +115,22 @@ while encapsulating and isolating implementation details. Components allow a pipeline to be assembled by using abstractions instead of having all the details defined in one place. When using a component in a pipeline, a user shouldn't need to know the implementation details of the component and should -only rely on the provided interface. The interface will have a version / revision, so that users understand which revision they are interfacing with. +only rely on the provided interface. A pipeline component defines its type which indicates in which context of the pipeline configuration the component can be used. For example, a component of type X can only be used according to the type X use-case. -For best experience with any systems made of components it's fundamental that components are single purpose, -isolated, reusable and resolvable. +For best experience with any systems made of components it's fundamental that components: - **Single purpose**: a component must focus on a single goal and the scope be as small as possible. -- **Isolation**: when a component is used in a pipeline, its implementation details should not leak outside the +- **Isolated**: when a component is used in a pipeline, its implementation details should not leak outside the component itself and into the main pipeline. -- **Reusability:** a component is designed to be used in different pipelines. +- **Reusable**: a component is designed to be used in different pipelines. Depending on the assumptions it's built on a component can be more or less generic. Generic components are more reusable but may require more customization. -- **Resolvable:** When a component depends on another component, this dependency must be explicit and trackable. +- **Versioned**: when using a component we must specify the version we are interested in. + The version identifies the exact interface and behavior of the component. +- **Resolvable**: when a component depends on another component, this dependency must be explicit and trackable. ## Proposal diff --git a/doc/ci/pipelines/downstream_pipelines.md b/doc/ci/pipelines/downstream_pipelines.md index 0b1963e1874..c6fffa0ec59 100644 --- a/doc/ci/pipelines/downstream_pipelines.md +++ b/doc/ci/pipelines/downstream_pipelines.md @@ -170,7 +170,10 @@ Use: - The `project` keyword to specify the full path to a downstream project. In [GitLab 15.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/367660), variable expansion is supported. -- The `branch` keyword to specify the name of a branch in the project specified by `project`. +- The `branch` keyword to specify the name of a branch or [tag](../../topics/git/tags.md) + in the project specified by `project`. If you use a tag when a branch exists with the same + name, the downstream pipeline fails to create with the error: `downstream pipeline can not be created, Ref is ambiguous`. + In [GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/10126), variable expansion is supported. diff --git a/doc/ci/testing/unit_test_report_examples.md b/doc/ci/testing/unit_test_report_examples.md index c14e4eedd7c..5d4cfa88d88 100644 --- a/doc/ci/testing/unit_test_report_examples.md +++ b/doc/ci/testing/unit_test_report_examples.md @@ -18,7 +18,10 @@ Use the following job in `.gitlab-ci.yml`. This includes the `artifacts:paths` k ```yaml ## Use https://github.com/sj26/rspec_junit_formatter to generate a JUnit report format XML file with rspec ruby: + image: ruby:3.0.4 stage: test + before_script: + - apt-get update -y && apt-get install -y bundler script: - bundle install - bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml diff --git a/doc/development/sidekiq/worker_attributes.md b/doc/development/sidekiq/worker_attributes.md index 48a222d65a0..4fcd8e33d5c 100644 --- a/doc/development/sidekiq/worker_attributes.md +++ b/doc/development/sidekiq/worker_attributes.md @@ -277,7 +277,7 @@ they prefer read replicas and will wait for replicas to catch up: | **Data Consistency** | **Description** | |--------------|-----------------------------| -| `:always` | The job is required to use the primary database (default). It should be used for workers that primarily perform writes or that have strict requirements around data consistency when reading their own writes. | +| `:always` | The job is required to use the primary database (default). It should be used for workers that primarily perform writes, have strict requirements around data consistency when reading their own writes, or are cron jobs. | | `:sticky` | The job prefers replicas, but switches to the primary for writes or when encountering replication lag. It should be used for jobs that require to be executed as fast as possible but can sustain a small initial queuing delay. | | `:delayed` | The job prefers replicas, but switches to the primary for writes. When encountering replication lag before the job starts, the job is retried once. If the replica is still not up to date on the next retry, it switches to the primary. It should be used for jobs where delaying execution further typically does not matter, such as cache expiration or web hooks execution. | |