summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/api/index.md1
-rw-r--r--doc/api/v3_to_v4.md11
-rw-r--r--doc/architecture/blueprints/runner_tokens/index.md17
-rw-r--r--doc/ci/environments/index.md4
-rw-r--r--doc/ci/yaml/index.md1
-rw-r--r--doc/ci/yaml/yaml_optimization.md24
-rw-r--r--doc/development/database/adding_database_indexes.md36
-rw-r--r--doc/development/database/database_lab.md39
-rw-r--r--doc/user/group/subgroups/index.md23
-rw-r--r--doc/user/project/integrations/webhook_events.md5
10 files changed, 80 insertions, 81 deletions
diff --git a/doc/api/index.md b/doc/api/index.md
index ef054318c5c..8075b667a67 100644
--- a/doc/api/index.md
+++ b/doc/api/index.md
@@ -59,7 +59,6 @@ month. Major API version changes, and removal of entire API versions, are done i
with major GitLab releases.
All deprecations and changes between versions are in the documentation.
-For the changes between v3 and v4, see the [v3 to v4 documentation](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/11-0-stable/doc/api/v3_to_v4.md).
### Current status
diff --git a/doc/api/v3_to_v4.md b/doc/api/v3_to_v4.md
deleted file mode 100644
index 875f4528c0e..00000000000
--- a/doc/api/v3_to_v4.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: 'https://gitlab.com/gitlab-org/gitlab-foss/-/blob/11-0-stable/doc/api/v3_to_v4.md'
-remove_date: '2023-01-31'
----
-
-This document was moved to [another location](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/11-0-stable/doc/api/v3_to_v4.md).
-
-<!-- This redirect file can be deleted after <2023-01-31>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/architecture/blueprints/runner_tokens/index.md b/doc/architecture/blueprints/runner_tokens/index.md
index 9dcedb8796d..b663183a98e 100644
--- a/doc/architecture/blueprints/runner_tokens/index.md
+++ b/doc/architecture/blueprints/runner_tokens/index.md
@@ -148,26 +148,25 @@ In addition, we should add the following columns to `ci_runners`:
future uses that may not be apparent.
```sql
-CREATE TABLE ci_runner (
+CREATE TABLE ci_runners (
...
creator_id bigint
registration_type int8
)
```
-The `ci_builds_runner_session` (or `ci_builds` or `ci_builds_metadata`) shall reference
-`ci_runner_machines`.
+The `ci_builds_metadata` table shall reference `ci_runner_machines`.
We might consider a more efficient way to store `contacted_at` than updating the existing record.
```sql
-CREATE TABLE ci_builds_runner_session (
+CREATE TABLE ci_builds_metadata (
...
runner_machine_id bigint NOT NULL
);
CREATE TABLE ci_runner_machines (
- id integer NOT NULL,
- machine_id character varying UNIQUE NOT NULL,
+ id bigint NOT NULL,
+ machine_xid character varying UNIQUE NOT NULL,
contacted_at timestamp without time zone,
version character varying,
revision character varying,
@@ -241,7 +240,7 @@ future after the legacy registration system is removed, and runners have been up
versions.
Job pings from such legacy runners results in a `ci_runner_machines` record containing a
-`<legacy>` `machine_id` field value.
+`<legacy>` `machine_xid` field value.
Not using the unique system ID means that all connected runners with the same token are
notified, instead of just the runner matching the exact system identifier. While not ideal, this is
@@ -320,9 +319,9 @@ using PAT tokens for example - such that every runner is associated with an owne
|------------------|----------:|---------|
| GitLab Rails app | | Create database migration to add columns to `ci_runners` table. |
| GitLab Rails app | | Create database migration to add `ci_runner_machines` table. |
-| GitLab Rails app | | Create database migration to add `ci_runner_machines.machine_id` foreign key to `ci_builds_runner_session` table. |
+| GitLab Rails app | | Create database migration to add `ci_runner_machines.id` foreign key to `ci_builds_metadata` table. |
| GitLab Rails app | | Create database migrations to add `allow_runner_registration_token` setting to `application_settings` and `namespace_settings` tables (default: `true`). |
-| GitLab Runner | | Use runner token + `system_id` JSON parameters in `POST /jobs/request` request in the [heartbeat request](https://gitlab.com/gitlab-org/gitlab/blob/c73c96a8ffd515295842d72a3635a8ae873d688c/lib/api/ci/helpers/runner.rb#L14-20) to update the `ci_runner_machines` cache/table. |
+| GitLab Rails app | | Use runner token + `system_id` JSON parameters in `POST /jobs/request` request in the [heartbeat request](https://gitlab.com/gitlab-org/gitlab/blob/c73c96a8ffd515295842d72a3635a8ae873d688c/lib/api/ci/helpers/runner.rb#L14-20) to update the `ci_runner_machines` cache/table. |
| GitLab Runner | | Start sending `system_id` value in `POST /jobs/request` request and other follow-up requests that require identifying the unique system. |
| GitLab Rails app | | Create service similar to `StaleGroupRunnersPruneCronWorker` service to clean up `ci_runner_machines` records instead of `ci_runners` records.<br/>Existing service continues to exist but focuses only on legacy runners. |
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index 0c412c85e47..f2a513fdde5 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -534,10 +534,6 @@ Also in the example, `GIT_STRATEGY` is set to `none`. If the
`stop_review_app` job is [automatically triggered](../environments/index.md#stop-an-environment),
the runner won't try to check out the code after the branch is deleted.
-The example also overwrites global variables. If your `stop` `environment` job depends
-on global variables, use [anchor variables](../yaml/yaml_optimization.md#yaml-anchors-for-variables) when you set the `GIT_STRATEGY`
-to change the job without overriding the global variables.
-
The `stop_review_app` job **must** have the following keywords defined:
- `when`, defined at either:
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 873e8c93fbd..48d23609542 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -4343,7 +4343,6 @@ deploy_review_job:
**Related topics**:
-- You can use [YAML anchors for variables](yaml_optimization.md#yaml-anchors-for-variables).
- [Predefined variables](../variables/predefined_variables.md) are variables the runner
automatically creates and makes available in the job.
- You can [configure runner behavior with variables](../runners/configure_runners.md#configure-runner-behavior-with-variables).
diff --git a/doc/ci/yaml/yaml_optimization.md b/doc/ci/yaml/yaml_optimization.md
index 2d875c0e250..aa447b0a8b1 100644
--- a/doc/ci/yaml/yaml_optimization.md
+++ b/doc/ci/yaml/yaml_optimization.md
@@ -189,30 +189,6 @@ job2:
- *some-script-after
```
-### YAML anchors for variables
-
-Use [YAML anchors](#anchors) with `variables` to repeat assignment
-of variables across multiple jobs. You can also use YAML anchors when a job
-requires a specific `variables` block that would otherwise override the global variables.
-
-The following example shows how override the `GIT_STRATEGY` variable without affecting
-the use of the `SAMPLE_VARIABLE` variable:
-
-```yaml
-# global variables
-variables: &global-variables
- SAMPLE_VARIABLE: sample_variable_value
- ANOTHER_SAMPLE_VARIABLE: another_sample_variable_value
-
-# a job that must set the GIT_STRATEGY variable, yet depend on global variables
-job_no_git_strategy:
- stage: cleanup
- variables:
- <<: *global-variables
- GIT_STRATEGY: none
- script: echo $SAMPLE_VARIABLE
-```
-
## Use `extends` to reuse configuration sections
You can use the [`extends` keyword](index.md#extends) to reuse configuration in
diff --git a/doc/development/database/adding_database_indexes.md b/doc/development/database/adding_database_indexes.md
index 6a401c804f5..e1d5a7af6d9 100644
--- a/doc/development/database/adding_database_indexes.md
+++ b/doc/development/database/adding_database_indexes.md
@@ -294,16 +294,14 @@ end
### Verify the MR was deployed and the index exists in production
-You can verify if the post-deploy migration was executed on GitLab.com by:
-
-- Executing `/chatops run auto_deploy status <merge_sha>`. If the output returns `db/gprd`,
- the post-deploy migration has been executed in the production database. More details in this
- [guide](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/post_deploy_migration/readme.md#how-to-determine-if-a-post-deploy-migration-has-been-executed-on-gitlabcom).
-- Use a meta-command in #database-lab, such as: `\d <index_name>`.
- - Ensure that the index is not [`invalid`](https://www.postgresql.org/docs/12/sql-createindex.html#:~:text=The%20psql%20%5Cd%20command%20will%20report%20such%20an%20index%20as%20INVALID).
-- Ask someone in #database to check if the index exists.
-- With proper access, you can also verify directly on production or in a
- production clone.
+1. Verify that the post-deploy migration was executed on GitLab.com using ChatOps with
+ `/chatops run auto_deploy status <merge_sha>`. If the output returns `db/gprd`,
+ the post-deploy migration has been executed in the production database. For more information, see
+ [How to determine if a post-deploy migration has been executed on GitLab.com](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/post_deploy_migration/readme.md#how-to-determine-if-a-post-deploy-migration-has-been-executed-on-gitlabcom).
+1. In the case of an [index created asynchronously](#schedule-the-index-to-be-created), wait
+ until the next week so that the index can be created over a weekend.
+1. Use [Database Lab](database_lab.md) to check [if creation was successful](database_lab.md#checking-indexes).
+ Ensure the output does not indicate the index is `invalid`.
### Add a migration to create the index synchronously
@@ -394,15 +392,15 @@ You must test the database index changes locally before creating a merge request
### Verify the MR was deployed and the index no longer exists in production
-You can verify if the MR was deployed to GitLab.com with
-`/chatops run auto_deploy status <merge_sha>`. To verify the existence of
-the index, you can:
-
-- Use a meta-command in `#database-lab`, for example: `\d <index_name>`.
-- Make sure the index no longer exists
-- Ask someone in `#database` to check if the index exists.
-- If you have access, you can verify directly on production or in a
- production clone.
+1. Verify that the post-deploy migration was executed on GitLab.com using ChatOps with
+ `/chatops run auto_deploy status <merge_sha>`. If the output returns `db/gprd`,
+ the post-deploy migration has been executed in the production database. For more information, see
+ [How to determine if a post-deploy migration has been executed on GitLab.com](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/post_deploy_migration/readme.md#how-to-determine-if-a-post-deploy-migration-has-been-executed-on-gitlabcom).
+1. In the case of an [index removed asynchronously](#schedule-the-index-to-be-removed), wait
+ until the next week so that the index can be created over a weekend.
+1. Use Database Lab [to check if removal was successful](database_lab.md#checking-indexes).
+ [Database Lab](database_lab.md)
+ should report an error when trying to find the removed index. If not, the index may still exist.
### Add a migration to destroy the index synchronously
diff --git a/doc/development/database/database_lab.md b/doc/development/database/database_lab.md
index b60091fa37c..162fc597cc4 100644
--- a/doc/development/database/database_lab.md
+++ b/doc/development/database/database_lab.md
@@ -75,6 +75,45 @@ the new index. `exec` does not return any results, only the time required to exe
After many changes, such as after a destructive query or an ineffective index,
you must start over. To reset your designated clone, run `reset`.
+#### Checking indexes
+
+Use Database Lab to check the status of an index with the meta-command `\d <index_name>`.
+
+Caveats:
+
+- Indexes are created in both the `main` and `ci` databases, so be sure to use the instance
+ that matches the table's `gitlab_schema`. For example, if the index is added to
+ [`ci_builds`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/ci_builds.yml#L14),
+ use `gitlab-production-ci`.
+- Database Lab typically has a small delay of a few hours. If more up-to-date information
+ is required, you can instead request access to a replica [via Teleport](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/Teleport/Connect_to_Database_Console_via_Teleport.md)
+
+For example: `\d index_design_management_designs_on_project_id` produces:
+
+```plaintext
+Index "public.index_design_management_designs_on_project_id"
+ Column | Type | Key? | Definition
+------------+---------+------+------------
+ project_id | integer | yes | project_id
+btree, for table "public.design_management_designs"
+```
+
+In the case of an invalid index, the output ends with `invalid`, like:
+
+```plaintext
+Index "public.index_design_management_designs_on_project_id"
+ Column | Type | Key? | Definition
+------------+---------+------+------------
+ project_id | integer | yes | project_id
+btree, for table "public.design_management_designs", invalid
+```
+
+If the index doesn't exist, JoeBot throws an error like:
+
+```plaintext
+ERROR: psql error: psql:/tmp/psql-query-932227396:1: error: Did not find any relation named "no_index".
+```
+
### Migration testing
For information on testing migrations, review our
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index 95c8e60af5d..8f0475885f4 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -66,16 +66,16 @@ In the hierarchy list, public groups with a private subgroup have an expand opti
for all users that indicate there is a subgroup. When users who are not direct or inherited members of
the private subgroup select expand (**{chevron-down}**), the nested subgroup does not display.
-If you prefer to keep information about the presence of nested subgroups private, we advise that you only
-add private subgroups to private parent groups.
+If you prefer to keep information about the presence of nested subgroups private, we advise that you
+add private subgroups only to private parent groups.
## Create a subgroup
Prerequisites:
-- You must either:
- - Have at least the Maintainer role for a group to create subgroups for it.
- - Have the [role determined by a setting](#change-who-can-create-subgroups). These users can create
+- You must have either:
+ - At least the Maintainer role for a group to create subgroups for it.
+ - The [role determined by a setting](#change-who-can-create-subgroups). These users can create
subgroups even if group creation is
[disabled by an Administrator](../../admin_area/index.md#prevent-a-user-from-creating-groups) in the user's settings.
@@ -92,8 +92,9 @@ To create a subgroup:
### Change who can create subgroups
-To create a subgroup, you must have at least the Maintainer role on the group, depending on the group's setting. By
-default:
+Prerequisite:
+
+- You must have at least the Maintainer role on the group, depending on the group's setting.
To change who can create subgroups on a group:
@@ -120,11 +121,11 @@ There is a bug that causes some pages in the parent group to be accessible by su
When you add a member to a group, that member is also added to all subgroups. The user's permissions are inherited from
the group's parent.
-Subgroup members can:
+Subgroup members can be:
-1. Be [direct members](../../project/members/index.md#add-users-to-a-project) of the subgroup.
-1. [Inherit membership](../../project/members/index.md#inherited-membership) of the subgroup from the subgroup's parent group.
-1. Be a member of a group that was [shared with the subgroup's top-level group](../manage.md#share-a-group-with-another-group).
+1. [Direct members](../../project/members/index.md#add-users-to-a-project) of the subgroup.
+1. [Inherited members](../../project/members/index.md#inherited-membership) of the subgroup from the subgroup's parent group.
+1. Members of a group that was [shared with the subgroup's top-level group](../manage.md#share-a-group-with-another-group).
```mermaid
flowchart RL
diff --git a/doc/user/project/integrations/webhook_events.md b/doc/user/project/integrations/webhook_events.md
index 13b8f74d1ca..bc6c59ed94f 100644
--- a/doc/user/project/integrations/webhook_events.md
+++ b/doc/user/project/integrations/webhook_events.md
@@ -1362,8 +1362,10 @@ Payload example:
## Job events
-- Number of retries [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/382046) in GitLab 15.6 [with a flag](../../../administration/feature_flags.md)
+- Number of retries (`retries_count`) [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/382046) in GitLab 15.6 [with a flag](../../../administration/feature_flags.md)
named `job_webhook_retries_count`. Disabled by default.
+- Pipeline name (`commit.name`) [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107963) in GitLab 15.8 [with a flag](../../../administration/feature_flags.md)
+ named `pipeline_name`. Enabled by default.
FLAG:
On self-managed GitLab, by default this feature is not available. To make it available,
@@ -1415,6 +1417,7 @@ Payload example:
},
"commit": {
"id": 2366,
+ "name": "Build pipeline",
"sha": "2293ada6b400935a1378653304eaf6221e0fdb8f",
"message": "test\n",
"author_name": "User",
View Lorry Controller Status