diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-31 15:08:09 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-31 15:08:09 +0300 |
commit | 0d0cddc9ce20c5a7d8a2723d0aa620ca184a711a (patch) | |
tree | 64f91b4d4ca74aa09d2a62ac5910820d087ed7cb /doc | |
parent | 6044caed20964a70c1ac6c5a3365d567ed96dfde (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
40 files changed, 139 insertions, 97 deletions
diff --git a/doc/administration/auth/ldap-troubleshooting.md b/doc/administration/auth/ldap-troubleshooting.md index c97231793db..ded5153133d 100644 --- a/doc/administration/auth/ldap-troubleshooting.md +++ b/doc/administration/auth/ldap-troubleshooting.md @@ -311,7 +311,7 @@ things to check to debug the situation. - You've waited an hour or [the configured interval](ldap-ee.md#adjusting-ldap-group-sync-schedule) for the group to sync. To speed up the process, either go to the GitLab group **Settings -> - Members** and press **Sync now** (sync one group) or [run the group sync rake + Members** and press **Sync now** (sync one group) or [run the group sync Rake task][group-sync-rake] (sync all groups). If all of the above looks good, jump in to a little more advanced debugging in @@ -351,7 +351,7 @@ GitLab syncs the `admin_group`. #### Sync all groups **(STARTER ONLY)** NOTE: **NOTE:** -To sync all groups manually when debugging is unnecessary, [use the rake +To sync all groups manually when debugging is unnecessary, [use the Rake task][group-sync-rake] instead. The output from a manual [group sync][group-sync] can show you what happens @@ -541,7 +541,7 @@ for each of these users. ### LDAP check -The [rake task to check LDAP][ldap-check] is a valuable tool +The [Rake task to check LDAP][ldap-check] is a valuable tool to help determine whether GitLab can successfully establish a connection to LDAP and can get so far as to even read users. @@ -550,7 +550,7 @@ with your configuration or a firewall blocking the connection. - Ensure you don't have a firewall blocking the connection, and that the LDAP server is accessible to the GitLab host. -- Look for an error message in the rake check output, which may lead to your LDAP configuration to +- Look for an error message in the Rake check output, which may lead to your LDAP configuration to confirm that the configuration values (specifically `host`, `port`, `bind_dn`, and `password`) are correct. - Look for [errors](#connection) in [the logs](#gitlab-logs) to further debug connection failures. diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md index dbcc37b25e7..60bfca74b6b 100644 --- a/doc/administration/file_hooks.md +++ b/doc/administration/file_hooks.md @@ -88,9 +88,9 @@ end ## Validation Writing your own file hook can be tricky and it's easier if you can check it -without altering the system. A rake task is provided so that you can use it +without altering the system. A Rake task is provided so that you can use it in a staging environment to test your file hook before using it in production. -The rake task will use a sample data and execute each of file hook. The output +The Rake task will use a sample data and execute each of file hook. The output should be enough to determine if the system sees your file hook and if it was executed without errors. diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md index 6852d08cc07..fe55539dc84 100644 --- a/doc/administration/geo/disaster_recovery/background_verification.md +++ b/doc/administration/geo/disaster_recovery/background_verification.md @@ -115,7 +115,7 @@ Feature.enable('geo_repository_reverification') Geo actively try to correct verification failures marking the repository to be resynced with a back-off period. If you want to reset them manually, this -rake task marks projects where verification has failed or the checksum mismatch +Rake task marks projects where verification has failed or the checksum mismatch to be resynced without the back-off period: For repositories: diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index 606e041c956..ee246381091 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -37,7 +37,7 @@ For information on how to resolve common errors reported from the UI, see If the UI is not working, or you are unable to log in, you can run the Geo health check manually to get this information as well as a few more details. -This rake task can be run on an app node in the **primary** or **secondary** +This Rake task can be run on an app node in the **primary** or **secondary** Geo nodes: ```shell @@ -70,7 +70,7 @@ All projects are in hashed storage? ... yes Checking Geo ... Finished ``` -Current sync information can be found manually by running this rake task on any +Current sync information can be found manually by running this Rake task on any **secondary** app node: ```shell @@ -147,9 +147,9 @@ This machine's Geo node name matches a database record ... no doc/administration/geo/replication/troubleshooting.md#can-geo-detect-the-current-node-correctly ``` -## Fixing errors found when running the Geo check rake task +## Fixing errors found when running the Geo check Rake task -When running this rake task, you may see errors if the nodes are not properly configured: +When running this Rake task, you may see errors if the nodes are not properly configured: ```shell sudo gitlab-rake gitlab:geo:check @@ -789,7 +789,7 @@ sudo gitlab-rake geo:db:refresh_foreign_tables ## Expired artifacts If you notice for some reason there are more artifacts on the Geo -secondary node than on the Geo primary node, you can use the rake task +secondary node than on the Geo primary node, you can use the Rake task to [cleanup orphan artifact files](../../../raketasks/cleanup.md#remove-orphan-artifact-files). On a Geo **secondary** node, this command will also clean up all Geo diff --git a/doc/administration/index.md b/doc/administration/index.md index 2ab4b3f710e..6fefe1a01d0 100644 --- a/doc/administration/index.md +++ b/doc/administration/index.md @@ -145,7 +145,7 @@ Learn how to install, configure, update, and maintain your GitLab instance. - [Repository checks](repository_checks.md): Periodic Git repository checks. - [Repository storage paths](repository_storage_paths.md): Manage the paths used to store repositories. - [Repository storage types](repository_storage_types.md): Information about the different repository storage types. -- [Repository storage rake tasks](raketasks/storage.md): A collection of rake tasks to list and migrate existing projects and attachments associated with it from Legacy storage to Hashed storage. +- [Repository storage Rake tasks](raketasks/storage.md): A collection of Rake tasks to list and migrate existing projects and attachments associated with it from Legacy storage to Hashed storage. - [Limit repository size](../user/admin_area/settings/account_and_limit_settings.md): Set a hard limit for your repositories' size. **(STARTER ONLY)** - [Static objects external storage](static_objects_external_storage.md): Set external storage for static objects in a repository. diff --git a/doc/administration/lfs/lfs_administration.md b/doc/administration/lfs/lfs_administration.md index d8631b05c14..a7ff624e1c6 100644 --- a/doc/administration/lfs/lfs_administration.md +++ b/doc/administration/lfs/lfs_administration.md @@ -136,7 +136,7 @@ and comparing the output of the returned headers. There are two ways to manually do the same thing as automatic uploading (described above). -**Option 1: rake task** +**Option 1: Rake task** ```shell rake gitlab:lfs:migrate diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md index abf00a5010a..c0edb43cc01 100644 --- a/doc/administration/raketasks/check.md +++ b/doc/administration/raketasks/check.md @@ -20,7 +20,7 @@ to prevent data integrity issues. However, if a Git operation is interrupted the locks may not be cleaned up properly. The following symptoms may indicate a problem with repository integrity. If users -experience these symptoms you may use the rake tasks described below to determine +experience these symptoms you may use the Rake tasks described below to determine exactly which repositories are causing the trouble. - Receiving an error when trying to push code - `remote: error: cannot lock ref` diff --git a/doc/administration/raketasks/geo.md b/doc/administration/raketasks/geo.md index 91c83b5f6ba..707ed1dbee0 100644 --- a/doc/administration/raketasks/geo.md +++ b/doc/administration/raketasks/geo.md @@ -59,7 +59,7 @@ sudo -u git -H bundle exec rake geo:git:housekeeping:gc RAILS_ENV=production ## Remove orphaned project registries Under certain conditions your project registry can contain obsolete records, you -can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`: +can remove them using the Rake task `geo:run_orphaned_project_registry_cleaner`: **Omnibus Installation** diff --git a/doc/administration/raketasks/github_import.md b/doc/administration/raketasks/github_import.md index 64ab56a57d4..4c6521f38ec 100644 --- a/doc/administration/raketasks/github_import.md +++ b/doc/administration/raketasks/github_import.md @@ -4,7 +4,7 @@ In order to retrieve and import GitHub repositories, you will need a [GitHub personal access token](https://github.com/settings/tokens). -A username should be passed as the second argument to the rake task +A username should be passed as the second argument to the Rake task which will become the owner of the project. You can resume an import with the same command. diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md index 6fd6c5dd8c1..c79a1aa6ba1 100644 --- a/doc/administration/raketasks/maintenance.md +++ b/doc/administration/raketasks/maintenance.md @@ -50,7 +50,7 @@ Git: /usr/bin/git ## Check GitLab configuration -Runs the following rake tasks: +Runs the following Rake tasks: - `gitlab:gitlab_shell:check` - `gitlab:gitaly:check` @@ -209,7 +209,7 @@ sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production ## Check TCP connectivity to a remote site Sometimes you need to know if your GitLab installation can connect to a TCP -service on another machine - perhaps a PostgreSQL or HTTPS server. A rake task +service on another machine - perhaps a PostgreSQL or HTTPS server. A Rake task is included to help you with this: **Omnibus Installation** @@ -258,7 +258,7 @@ sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4] See the [upgrade documentation](../../update/README.md#checking-for-background-migrations-before-upgrading) for how to check that migrations are complete when upgrading GitLab. -To check the status of specific migrations, you can use the following rake task: +To check the status of specific migrations, you can use the following Rake task: ```shell sudo gitlab-rake db:migrate:status diff --git a/doc/administration/raketasks/storage.md b/doc/administration/raketasks/storage.md index a14c8ed7969..1e487a317c9 100644 --- a/doc/administration/raketasks/storage.md +++ b/doc/administration/raketasks/storage.md @@ -1,6 +1,6 @@ # Repository Storage Rake Tasks -This is a collection of rake tasks you can use to help you list and migrate +This is a collection of Rake tasks you can use to help you list and migrate existing projects and attachments associated with it from Legacy storage to the new Hashed storage type. @@ -46,7 +46,7 @@ Any error or warning will be logged in Sidekiq's log file. NOTE: **Note:** If Geo is enabled, each project that is successfully migrated generates an event to replicate the changes on any **secondary** nodes. -You only need the `gitlab:storage:migrate_to_hashed` rake task to migrate your repositories, but we have additional +You only need the `gitlab:storage:migrate_to_hashed` Rake task to migrate your repositories, but we have additional commands below that helps you inspect projects and attachments in both legacy and hashed storage. ## Rollback from Hashed storage to Legacy storage diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md index 2dc07bc09d6..6dae9b71e1f 100644 --- a/doc/administration/raketasks/uploads/migrate.md +++ b/doc/administration/raketasks/uploads/migrate.md @@ -7,12 +7,12 @@ After [configuring the object storage](../../uploads.md#using-object-storage-cor >**Note:** All of the processing will be done in a background worker and requires **no downtime**. -### All-in-one rake task +### All-in-one Rake task -GitLab provides a wrapper rake task that migrates all uploaded files - avatars, +GitLab provides a wrapper Rake task that migrates all uploaded files - avatars, logos, attachments, favicon, etc. - to object storage in one go. Under the hood, -it invokes individual rake tasks to migrate files falling under each of this -category one by one. The specifications of these individual rake tasks are +it invokes individual Rake tasks to migrate files falling under each of this +category one by one. The specifications of these individual Rake tasks are described in the next section. **Omnibus Installation** @@ -27,12 +27,12 @@ gitlab-rake "gitlab:uploads:migrate:all" sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate:all ``` -### Individual rake tasks +### Individual Rake tasks >**Note:** -If you already ran the rake task mentioned above, no need to run these individual rake tasks as that has been done automatically. +If you already ran the Rake task mentioned above, no need to run these individual Rake tasks as that has been done automatically. -The rake task uses 3 parameters to find uploads to migrate. +The Rake task uses 3 parameters to find uploads to migrate. Parameter | Type | Description --------- | ---- | ----------- @@ -140,12 +140,12 @@ the migration. A configuration setting will be added soon to allow migrating from object storage to local files with only a brief moment of downtime for configuration changes. To follow progress, see the [relevant issue](https://gitlab.com/gitlab-org/gitlab/issues/30979). -### All-in-one rake task +### All-in-one Rake task -GitLab provides a wrapper rake task that migrates all uploaded files - avatars, +GitLab provides a wrapper Rake task that migrates all uploaded files - avatars, logos, attachments, favicon, etc. - to local storage in one go. Under the hood, -it invokes individual rake tasks to migrate files falling under each of this -category one by one. For details on these rake tasks please [refer to the section above](#individual-rake-tasks), +it invokes individual Rake tasks to migrate files falling under each of this +category one by one. For details on these Rake tasks please [refer to the section above](#individual-rake-tasks), keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`. **Omnibus Installation** diff --git a/doc/administration/raketasks/uploads/sanitize.md b/doc/administration/raketasks/uploads/sanitize.md index 3e9b44a24fb..c00399a27cf 100644 --- a/doc/administration/raketasks/uploads/sanitize.md +++ b/doc/administration/raketasks/uploads/sanitize.md @@ -29,7 +29,7 @@ sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:rem This command by default runs in dry mode and it doesn't remove EXIF data. It can be used for checking if (and how many) images should be sanitized. -The rake task accepts following parameters. +The Rake task accepts following parameters. Parameter | Type | Description --------- | ---- | ----------- @@ -41,7 +41,7 @@ Parameter | Type | Description `since` | date | Run sanitization only for uploads newer than given date (e.g. `2019-05-01`) If you have too many uploads, you can speed up sanitization by setting -`sleep_time` to a lower value or by running multiple rake tasks in parallel, +`sleep_time` to a lower value or by running multiple Rake tasks in parallel, each with a separate range of upload IDs (by setting `start_id` and `stop_id`). To run the command without dry mode and remove EXIF data from all uploads, you can use: @@ -58,7 +58,7 @@ sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:rem Because the output of commands will be probably long, the output is written also into exif.log file. -If sanitization fails for an upload, an error message should be in the output of the rake task (typical reasons may +If sanitization fails for an upload, an error message should be in the output of the Rake task (typical reasons may be that the file is missing in the storage or it's not a valid image). Please [report](https://gitlab.com/gitlab-org/gitlab-foss/issues/new) any issues at `gitlab.com` and use prefix 'EXIF' in issue title with the error output and (if possible) the image. diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md index ba0d511b718..f92106a69ca 100644 --- a/doc/administration/repository_storage_types.md +++ b/doc/administration/repository_storage_types.md @@ -162,7 +162,7 @@ either runs on the same machine as your repositories are located, or may login t to access data (for example, a remote backup solution). To schedule a complete rollout, see the -[rake task documentation for storage migration][rake/migrate-to-hashed] for instructions. +[Rake task documentation for storage migration][rake/migrate-to-hashed] for instructions. If you do have any existing integration, you may want to do a small rollout first, to validate. You can do so by specifying a range with the operation. @@ -186,7 +186,7 @@ projects: 1. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox. To schedule a complete rollback, see the -[rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions. +[Rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions. The rollback task also supports specifying a range of Project IDs. Here is an example of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation: diff --git a/doc/administration/timezone.md b/doc/administration/timezone.md index bc6eaf57a23..fa0fbb43433 100644 --- a/doc/administration/timezone.md +++ b/doc/administration/timezone.md @@ -15,7 +15,7 @@ To see all available time zones, run `bundle exec rake time:zones:all`. For Omnibus installations, run `gitlab-rake time:zones:all`. NOTE: **Note:** -Currently, this rake task does not list timezones in TZInfo format required by GitLab Omnibus during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672). +Currently, this Rake task does not list timezones in TZInfo format required by GitLab Omnibus during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672). ## Changing time zone in Omnibus installations diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md index c864fc7b2b6..77a63112ea3 100644 --- a/doc/administration/troubleshooting/elasticsearch.md +++ b/doc/administration/troubleshooting/elasticsearch.md @@ -204,7 +204,7 @@ If it is, check on the Elasticsearch side to determine if the `gitlab-production name for the GitLab index) exists. If it exists, manually delete it on the Elasticsearch side and attempt to recreate it from the [`create_empty_index`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) -rake task. +Rake task. If you still encounter issues, try creating an index manually on the Elasticsearch instance. The details of the index aren't important here, as we want to test if indices @@ -220,7 +220,7 @@ during the indexing of projects. If errors do occur, they will either stem from something you are familiar with, contact GitLab support for guidance. - Within the Elasticsearch instance itself. See if the error is [documented and has a fix](../../integration/elasticsearch.md#troubleshooting). If not, speak with your Elasticsearch admin. -If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following rake tasks: +If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following Rake tasks: - [`sudo gitlab-rake gitlab:elastic:index_projects_status`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) (shows the overall status) - [`sudo gitlab-rake gitlab:elastic:projects_not_indexed`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) (shows specific projects that are not indexed) diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md index 8b06d6ff530..0a4e65add4f 100644 --- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md +++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md @@ -117,7 +117,7 @@ and they will assist you with any issues you are having. kubectl get events -w --namespace=gitlab ``` -- Most of the useful GitLab tools (console, rake tasks, etc) are found in the task-runner +- Most of the useful GitLab tools (console, Rake tasks, etc) are found in the task-runner pod. You may enter it and run commands inside or run them from the outside: ```shell diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md index f53c4e63bcb..45cffb64671 100644 --- a/doc/administration/uploads.md +++ b/doc/administration/uploads.md @@ -116,7 +116,7 @@ _The uploads are stored by default in ``` 1. Save the file and [reconfigure GitLab][] for the changes to take effect. -1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md). +1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md). **In installations from source:** @@ -139,7 +139,7 @@ _The uploads are stored by default in ``` 1. Save the file and [restart GitLab][] for the changes to take effect. -1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md). +1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md). ### Oracle Cloud S3 connection settings @@ -193,7 +193,7 @@ _The uploads are stored by default in ``` 1. Save the file and [reconfigure GitLab][] for the changes to take effect. -1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md). +1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md). --- @@ -224,7 +224,7 @@ _The uploads are stored by default in ``` 1. Save the file and [reconfigure GitLab][] for the changes to take effect. -1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md). +1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md). [reconfigure gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab" [restart gitlab]: restart_gitlab.md#installations-from-source "How to restart GitLab" diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md index 32074f9bced..8ad2e84a03e 100644 --- a/doc/api/project_import_export.md +++ b/doc/api/project_import_export.md @@ -5,7 +5,7 @@ See also: - [Project import/export documentation](../user/project/settings/import_export.md). -- [Project import/export administration rake tasks](../administration/raketasks/project_import_export.md). **(CORE ONLY)** +- [Project import/export administration Rake tasks](../administration/raketasks/project_import_export.md). **(CORE ONLY)** ## Schedule an export diff --git a/doc/api/releases/index.md b/doc/api/releases/index.md index c2dd9108364..47cef0e5fa0 100644 --- a/doc/api/releases/index.md +++ b/doc/api/releases/index.md @@ -456,6 +456,33 @@ Example response: } ``` +## Collect release evidence **(PREMIUM ONLY)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199065) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10. + +Create Evidence for an existing Release. + +```plaintext +POST /projects/:id/releases/:tag_name/evidence +``` + +| Attribute | Type | Required | Description | +| ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- | +| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). | +| `tag_name` | string | yes | The tag where the release will be created from. | + +Example request: + +```shell +curl --request POST --header "PRIVATE-TOKEN: gDybLx3yrUK_HLp3qPjS" "https://gitlab.example.com/api/v4/projects/24/releases/v0.1/evidence" +``` + +Example response: + +```json +200 +``` + ## Update a release Update a Release. diff --git a/doc/development/architecture.md b/doc/development/architecture.md index c36b03e9769..f1801320ae0 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -725,7 +725,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`. ### Maintenance Tasks -[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/raketasks/maintenance.md). +[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides Rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance Rake tasks](../raketasks/maintenance.md). In a nutshell, do the following: ```shell diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md index 2e4451949aa..e090281f2bf 100644 --- a/doc/development/dangerbot.md +++ b/doc/development/dangerbot.md @@ -31,7 +31,7 @@ from the start of the merge request. ## Run Danger locally -A subset of the current checks can be run locally with the following rake task: +A subset of the current checks can be run locally with the following Rake task: ```shell bin/rake danger_local diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index 20f9fb95440..26d14d8830c 100644 --- a/doc/development/elasticsearch.md +++ b/doc/development/elasticsearch.md @@ -25,7 +25,7 @@ Developers making significant changes to Elasticsearch queries should test their See the [Elasticsearch GDK setup instructions](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/elasticsearch.md) -## Helpful rake tasks +## Helpful Rake tasks - `gitlab:elastic:test:index_size`: Tells you how much space the current index is using, as well as how many documents are in the index. - `gitlab:elastic:test:index_size_change`: Outputs index size, reindexes, and outputs index size again. Useful when testing improvements to indexing size. @@ -34,7 +34,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons ## How does it work? -The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb). +The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a Rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb). After initial indexing is complete, create, update, and delete operations for all models except projects (see [#207494](https://gitlab.com/gitlab-org/gitlab/issues/207494)) are tracked in a Redis [`ZSET`](https://redis.io/topics/data-types#sorted-sets). A regular `sidekiq-cron` `ElasticIndexBulkCronWorker` processes this queue, updating many Elasticsearch documents at a time with the [Bulk Request API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html). diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md index edfde53f5ec..ffa95d86876 100644 --- a/doc/development/experiment_guide/index.md +++ b/doc/development/experiment_guide/index.md @@ -56,7 +56,9 @@ The author then adds a comment to this piece of code and adds a link to the issu ``` - Track necessary events. See the [telemetry guide](../../telemetry/index.md) for details. -- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel: +- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) in the +[appropriate channel](../feature_flags/controls.md#where-to-run-commands) to enable the feature flag and start the experiment. +For visibility, please also share any commands run against production in the `#s_growth` channel: ```shell /chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true diff --git a/doc/development/file_storage.md b/doc/development/file_storage.md index adfb92acc54..e16fe7eba5b 100644 --- a/doc/development/file_storage.md +++ b/doc/development/file_storage.md @@ -50,9 +50,9 @@ In the case of Issues/MR/Notes Markdown attachments, there is a different approa instead of basing the path into a mutable variable `:project_path_with_namespace`, it's possible to use the hash of the project ID instead, if project migrates to the new approach (introduced in 10.2). -> Note: We provide an [all-in-one rake task] to migrate all uploads to object +> Note: We provide an [all-in-one Rake task] to migrate all uploads to object > storage in one go. If a new Uploader class or model type is introduced, make -> sure you add a rake task invocation corresponding to it to the [category +> sure you add a Rake task invocation corresponding to it to the [category > list]. ### Path segments diff --git a/doc/development/import_project.md b/doc/development/import_project.md index 7bfcbaf07f8..0701279ddea 100644 --- a/doc/development/import_project.md +++ b/doc/development/import_project.md @@ -45,7 +45,7 @@ There is also an option to [import the project via GitHub](../user/project/impor This method will take longer to import than the other methods and will depend on several factors. It's recommended to use the other methods. -### Importing via a rake task +### Importing via a Rake task [`import.rake`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/tasks/gitlab/import_export/import.rake) was introduced for importing large GitLab project exports. diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md index 83dd5027a02..3bc638ca6f2 100644 --- a/doc/development/rake_tasks.md +++ b/doc/development/rake_tasks.md @@ -129,11 +129,11 @@ To run several tests inside one directory: - `bin/rspec spec/requests/api/` for the rspec tests if you want to test API only -### Speed-up tests, rake tasks, and migrations +### Speed-up tests, Rake tasks, and migrations [Spring](https://github.com/rails/spring) is a Rails application preloader. It speeds up development by keeping your application running in the background so -you don't need to boot it every time you run a test, rake task or migration. +you don't need to boot it every time you run a test, Rake task or migration. If you want to use it, you'll need to export the `ENABLE_SPRING` environment variable to `1`: @@ -247,7 +247,7 @@ To generate GraphQL documentation based on the GitLab schema, run: bundle exec rake gitlab:graphql:compile_docs ``` -In its current state, the rake task: +In its current state, the Rake task: - Generates output for GraphQL objects. - Places the output at `doc/api/graphql/reference/index.md`. @@ -270,4 +270,4 @@ To generate GraphQL schema files based on the GitLab schema, run: bundle exec rake gitlab:graphql:schema:dump ``` -This uses graphql-ruby's built-in rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats. +This uses graphql-ruby's built-in Rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats. diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md index 3f1493c3ed2..6314eaad35f 100644 --- a/doc/integration/elasticsearch.md +++ b/doc/integration/elasticsearch.md @@ -141,7 +141,7 @@ The following Elasticsearch settings are available: | Parameter | Description | | ----------------------------------------------------- | ----------- | -| `Elasticsearch indexing` | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). | +| `Elasticsearch indexing` | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special Rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). | | `Search with Elasticsearch enabled` | Enables/disables using Elasticsearch in search. | | `URL` | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). | | `Number of Elasticsearch shards` | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) | @@ -174,7 +174,7 @@ If no namespaces or projects are selected, no Elasticsearch indexing will take p CAUTION: **Warning**: If you have already indexed your instance, you will have to regenerate the index in order to delete all existing data -for filtering to work correctly. To do this run the rake tasks `gitlab:elastic:create_empty_index` and +for filtering to work correctly. To do this run the Rake tasks `gitlab:elastic:create_empty_index` and `gitlab:elastic:clear_index_status`. Afterwards, removing a namespace or a project from the list will delete the data from the Elasticsearch index as expected. @@ -298,7 +298,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq This enqueues a Sidekiq job for each project that needs to be indexed. You can view the jobs in **Admin Area > Monitoring > Background Jobs > Queues Tab** - and click `elastic_indexer`, or you can query indexing status using a rake task: + and click `elastic_indexer`, or you can query indexing status using a Rake task: ```shell # Omnibus installations @@ -402,7 +402,7 @@ For repository and snippet files, GitLab will only index up to 1 MiB of content, ## GitLab Elasticsearch Rake Tasks -There are several rake tasks available to you via the command line: +There are several Rake tasks available to you via the command line: - [`sudo gitlab-rake gitlab:elastic:index`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake) - This is a wrapper task. It does the following: @@ -438,7 +438,7 @@ There are several rake tasks available to you via the command line: ### Environment Variables -In addition to the rake tasks, there are some environment variables that can be used to modify the process: +In addition to the Rake tasks, there are some environment variables that can be used to modify the process: | Environment Variable | Data Type | What it does | | -------------------- |:---------:| ---------------------------------------------------------------------------- | @@ -550,7 +550,7 @@ Here are some common pitfalls and how to overcome them: - **I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything** - You will need to re-run all the rake tasks to re-index the database, repositories, and wikis. + You will need to re-run all the Rake tasks to re-index the database, repositories, and wikis. - **The indexing process is taking a very long time** @@ -564,7 +564,7 @@ Here are some common pitfalls and how to overcome them: When performing the initial indexing of blobs, we lock all projects until the project finishes indexing. It could happen that an error during the process causes one or multiple projects to remain locked. In order to unlock them, - run the `gitlab:elastic:clear_locked_projects` rake task. + run the `gitlab:elastic:clear_locked_projects` Rake task. - **"Can't specify parent if no parent field has been configured"** @@ -632,7 +632,7 @@ Here are some common pitfalls and how to overcome them: ``` You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticseach Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a). - Once you have corrected the formatting of the URL, delete the index (via the [dedicated rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index). + Once you have corrected the formatting of the URL, delete the index (via the [dedicated Rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index). ### Reverting to basic search diff --git a/doc/migrate_ci_to_ce/README.md b/doc/migrate_ci_to_ce/README.md index 86720aca158..10f22af30f7 100644 --- a/doc/migrate_ci_to_ce/README.md +++ b/doc/migrate_ci_to_ce/README.md @@ -131,8 +131,8 @@ First upgrade your GitLab server to version 8.0: After you update, go to the admin panel and temporarily disable CI. As an administrator, go to **Admin Area** -> **Settings**, and under -**Continuous Integration** uncheck **Disable to prevent CI usage until rake -ci:migrate is run (8.0 only)**. +**Continuous Integration** uncheck **Disable to prevent CI usage until `rake +ci:migrate` is run (8.0 only)**. ### 3. CI settings are now in GitLab @@ -184,7 +184,7 @@ sudo -u gitlab_ci -H bundle exec rake backup:show_secrets RAILS_ENV=production ### 2. SQL data and build traces Create your final CI data export. If you are converting from MySQL to -PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When +PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the Rake command. When the command finishes it will print the path to your data export archive; you will need this file later. diff --git a/doc/raketasks/README.md b/doc/raketasks/README.md index 7726bce4daf..8faace58599 100644 --- a/doc/raketasks/README.md +++ b/doc/raketasks/README.md @@ -19,6 +19,8 @@ The following are available Rake tasks: |:-------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------| | [Back up and restore](backup_restore.md) | Back up, restore, and migrate GitLab instances between servers. | | [Clean up](cleanup.md) | Clean up unneeded items GitLab instances. | +| [Development](../development/rake_tasks.md) | Tasks for GitLab contributors. | +| [Elasticsearch](../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) | Maintain Elasticsearch in a GitLab instance. | | [Enable namespaces](features.md) | Enable usernames and namespaces for user projects. | | [General maintenance](../administration/raketasks/maintenance.md) | General maintenance and self-check tasks. | | [Geo maintenance](../administration/raketasks/geo.md) **(PREMIUM ONLY)** | [Geo](../administration/geo/replication/index.md)-related maintenance. | diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index 1a1afe7b555..19065b27275 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -109,7 +109,7 @@ kubectl exec -it <gitlab task-runner pod> backup-utility Similarly to the Kubernetes case, if you have scaled out your GitLab cluster to use multiple application servers, you should pick a designated node (that won't be auto-scaled away) for running the -backup rake task. Because the backup rake task is tightly coupled to +backup Rake task. Because the backup Rake task is tightly coupled to the main Rails application, this is typically a node on which you're also running Unicorn/Puma and/or Sidekiq. @@ -171,7 +171,7 @@ the GitLab container according to the documentation, it should be under `/srv/gitlab/config`. For [GitLab Helm chart Installations](https://gitlab.com/gitlab-org/charts/gitlab) on a -Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions. +Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions. You may also want to back up any TLS keys and certificates, and your [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079). @@ -819,7 +819,7 @@ a Kubernetes cluster, the restore task expects the restore directories to be emp However, with docker and Kubernetes volume mounts, some system level directories may be created at the volume roots, like `lost+found` directory found in Linux operating systems. These directories are usually owned by `root`, which can -cause access permission errors since the restore rake task runs as `git` user. +cause access permission errors since the restore Rake task runs as `git` user. So, to restore a GitLab installation, users have to confirm the restore target directories are empty. @@ -875,8 +875,8 @@ to export / backup your data yourself from GitLab.com. Issues are stored in the database. They can't be stored in Git itself. To migrate your repositories from one server to another with an up-to-date version of -GitLab, you can use the [import rake task](import.md) to do a mass import of the -repository. Note that if you do an import rake task, rather than a backup restore, you +GitLab, you can use the [import Rake task](import.md) to do a mass import of the +repository. Note that if you do an import Rake task, rather than a backup restore, you will have all your repositories, but not any other data. ## Troubleshooting @@ -893,7 +893,7 @@ psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING: no privileges were Be advised that, backup is successfully restored in spite of these warnings. -The rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to. +The Rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to. Those objects have no influence on the database backup/restore but they give this annoying warning. For more information see similar questions on PostgreSQL issue tracker[here](https://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](https://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](https://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql). diff --git a/doc/raketasks/cleanup.md b/doc/raketasks/cleanup.md index b0045b7c968..ef69b1cce15 100644 --- a/doc/raketasks/cleanup.md +++ b/doc/raketasks/cleanup.md @@ -9,7 +9,7 @@ GitLab provides Rake tasks for cleaning up GitLab instances. DANGER: **Danger:** Do not run this within 12 hours of a GitLab upgrade. This is to ensure that all background migrations have finished, which otherwise may lead to data loss. -When you remove LFS files from a repository's history, they become orphaned and continue to consume disk space. With this rake task, you can remove invalid references from the database, which +When you remove LFS files from a repository's history, they become orphaned and continue to consume disk space. With this Rake task, you can remove invalid references from the database, which will allow garbage collection of LFS files. For example: @@ -36,7 +36,7 @@ By default, this task does not delete anything but shows how many file reference delete. Run the command with `DRY_RUN=false` if you actually want to delete the references. You can also use `LIMIT={number}` parameter to limit the number of deleted references. -Note that this rake task only removes the references to LFS files. Unreferenced LFS files will be garbage-collected +Note that this Rake task only removes the references to LFS files. Unreferenced LFS files will be garbage-collected later (once a day). If you need to garbage collect them immediately, run `rake gitlab:cleanup:orphan_lfs_files` described below. diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md index 9592ae3df88..886154aac6d 100644 --- a/doc/security/two_factor_authentication.md +++ b/doc/security/two_factor_authentication.md @@ -65,7 +65,7 @@ The following are important notes about 2FA: ## Disabling 2FA for everyone There may be some special situations where you want to disable 2FA for everyone -even when forced 2FA is disabled. There is a rake task for that: +even when forced 2FA is disabled. There is a Rake task for that: ```shell # Omnibus installations diff --git a/doc/university/support/README.md b/doc/university/support/README.md index ab40f1b3610..8889638b086 100644 --- a/doc/university/support/README.md +++ b/doc/university/support/README.md @@ -62,14 +62,14 @@ Sometimes we need to upgrade customers from old versions of GitLab to latest, so - Users - Groups - Projects - - [Backup using our Backup rake task](../../raketasks/backup_restore.md#creating-a-backup-of-the-gitlab-system) + - [Backup using our Backup Rake task](../../raketasks/backup_restore.md#creating-a-backup-of-the-gitlab-system) - [Upgrade to 5.0 source using our Upgrade documentation](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/4.2-to-5.0.md) - [Upgrade to 5.1 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/5.0-to-5.1.md) - [Upgrade to 6.0 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/5.1-to-6.0.md) - [Upgrade to 7.14 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/6.x-or-7.x-to-7.14.md) - [Perform the MySQL to PostgreSQL migration to convert your backup](../../update/mysql_to_postgresql.md) - [Upgrade to Omnibus 7.14](https://docs.gitlab.com/omnibus/update/README.html#upgrading-from-a-non-omnibus-installation-to-an-omnibus-installation) - - [Restore backup using our Restore rake task](../../raketasks/backup_restore.md#restore) + - [Restore backup using our Restore Rake task](../../raketasks/backup_restore.md#restore) - [Upgrade to latest EE](https://about.gitlab.com/update/) - (GitLab inc. only) Acquire and apply a license for the Enterprise Edition product, ask in #support - Perform a downgrade from [EE to CE](../../downgrade_ee_to_ce/README.md) diff --git a/doc/update/README.md b/doc/update/README.md index b183df22589..a72e0e1e6ae 100644 --- a/doc/update/README.md +++ b/doc/update/README.md @@ -147,7 +147,7 @@ puts Sidekiq::Queue.new("background_migration").size Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size ``` -There is also a [rake task](../administration/raketasks/maintenance.md#display-status-of-database-migrations) +There is also a [Rake task](../administration/raketasks/maintenance.md#display-status-of-database-migrations) for displaying the status of each database migration. ## Upgrading to a new major version diff --git a/doc/update/restore_after_failure.md b/doc/update/restore_after_failure.md index 99329fdceb3..e01ae409bb3 100644 --- a/doc/update/restore_after_failure.md +++ b/doc/update/restore_after_failure.md @@ -45,7 +45,7 @@ need to do. ### GitLab 8.6+ -Pass the version to a database rake task to manually mark the migration as +Pass the version to a database Rake task to manually mark the migration as complete. ```shell @@ -56,7 +56,7 @@ sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857 sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857] ``` -Once the migration is successfully marked, run the rake `db:migrate` task again. +Once the migration is successfully marked, run the Rake `db:migrate` task again. You will likely have to repeat this process several times until all failed migrations are marked complete. @@ -77,6 +77,6 @@ ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) V exit ``` -Once the migration is successfully marked, run the rake `db:migrate` task again. +Once the migration is successfully marked, run the Rake `db:migrate` task again. You will likely have to repeat this process several times until all failed migrations are marked complete. diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md index 80b14c40e0a..ede2369dd3e 100644 --- a/doc/user/project/import/github.md +++ b/doc/user/project/import/github.md @@ -14,7 +14,7 @@ GitHub repositories using a [personal access token](#using-a-github-token), but this method is not recommended because it cannot associate all user activity (such as issues and pull requests) with matching GitLab users. If you are an administrator of a self-managed GitLab instance, you can also use the -[GitHub rake task](../../../administration/raketasks/github_import.md) to import projects from +[GitHub Rake task](../../../administration/raketasks/github_import.md) to import projects from GitHub without the constraints of a Sidekiq worker. The following aspects of a project are imported: diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md index 86f00cdcc1c..b961478ea6d 100644 --- a/doc/user/project/integrations/prometheus.md +++ b/doc/user/project/integrations/prometheus.md @@ -882,7 +882,7 @@ If the "No data found" screen continues to appear, it could be due to: are not labeled correctly. To test this, connect to the Prometheus server and [run a query](prometheus_library/kubernetes.md#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG` with the name of your environment. -- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics rake task](../../../administration/raketasks/maintenance.md#import-common-metrics). +- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics Rake task](../../../administration/raketasks/maintenance.md#import-common-metrics). [autodeploy]: ../../../topics/autodevops/index.md#auto-deploy [kubernetes]: https://kubernetes.io diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md index 53559ef1bb8..4a32644420f 100644 --- a/doc/user/project/releases/index.md +++ b/doc/user/project/releases/index.md @@ -244,16 +244,20 @@ You can also edit an existing tag to add release notes: > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26019) in GitLab 12.6. -Each time a new release is created, specific related data is collected in -parallel. This dataset will be a snapshot this new release (including linked -milestones and issues) at moment of creation. Such collection of data will -provide a chain of custody and facilitate processes like external audits, for example. +Each time a release is created, GitLab takes a snapshot of data that's related to it. +This data is called Release Evidence. It includes linked milestones and issues, and +it is taken at moment the release is created. It provides a chain of custody and can +facilitate processes like external audits, for example. -The gathered evidence data is stored in the database upon creation of a new -release as a JSON object. In GitLab 12.6, a link to -the evidence data is provided for [each Release](#releases-list). +You can also [use the API](../../../api/releases/index.md#collect-release-evidence-premium-only) to +generate Release Evidence for an existing release. Because of this, [each release](#releases-list) +can have multiple Release Evidence snapshots. You can view the Release Evidence and +its details on the Release page. -Here is what this object can look like: +Release Evidence is stored as a JSON object, so you can compare evidence by using +commonly-available tools. + +Here is an example of a Release Evidence object: ```json { @@ -319,7 +323,14 @@ Please note that Release Evidence's data is collected regardless of this feature flag, which only enables or disables the display of the data on the Releases page. -### Scheduled Evidence creation +### Collect release evidence **(PREMIUM ONLY)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199065) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10. + +Evidence collection can be initiated by using an [API call](../../../api/releases/index.md#collect-release-evidence-premium-only) at any time. Evidence snapshots are visible on +the Release page, along with the timestamp the Evidence was collected. + +### Schedule release evidence collection > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23697) in GitLab 12.8. diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md index 9ff9f76dadb..04ad7b30aec 100644 --- a/doc/user/project/settings/import_export.md +++ b/doc/user/project/settings/import_export.md @@ -11,7 +11,7 @@ The **GitLab import/export** button is displayed if the project import option is See also: - [Project import/export API](../../../api/project_import_export.md) -- [Project import/export administration rake tasks](../../../administration/raketasks/project_import_export.md) **(CORE ONLY)** +- [Project import/export administration Rake tasks](../../../administration/raketasks/project_import_export.md) **(CORE ONLY)** - [Group import/export API](../../../api/group_import_export.md) To set up a project import/export: |