diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-02-16 21:14:47 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-02-16 21:14:47 +0300 |
commit | 5e65d4f6c601e6636d171dbf8586949fedc334d7 (patch) | |
tree | 68377df58b2318fedd44affaf29e59ec436e6a71 /doc | |
parent | 5382b5cdc41d11fc50c47e226c48660aa0ddff55 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/api/container_registry.md | 2 | ||||
-rw-r--r-- | doc/api/graphql/reference/index.md | 2 | ||||
-rw-r--r-- | doc/integration/elasticsearch.md | 2 | ||||
-rw-r--r-- | doc/user/clusters/migrating_from_gma_to_project_template.md | 76 | ||||
-rw-r--r-- | doc/user/group/roadmap/index.md | 4 | ||||
-rw-r--r-- | doc/user/group/value_stream_analytics/index.md | 15 | ||||
-rw-r--r-- | doc/user/project/import/bitbucket.md | 2 | ||||
-rw-r--r-- | doc/user/project/merge_requests/commits.md | 35 |
8 files changed, 58 insertions, 80 deletions
diff --git a/doc/api/container_registry.md b/doc/api/container_registry.md index 8fc7c4dc4fe..b61ec34b882 100644 --- a/doc/api/container_registry.md +++ b/doc/api/container_registry.md @@ -441,7 +441,7 @@ These are different from project or personal access tokens in the GitLab applica ### Listing all container repositories ```plaintext -GET /v2/_catalogue +GET /v2/_catalog ``` To list all container repositories on your GitLab instance, admin credentials are required: diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md index 6d3115e29af..11509e9f8a4 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -5168,7 +5168,7 @@ Input type: `VulnerabilityRevertToDetectedInput` ### `Mutation.workItemCreate` -Available only when feature flag `work_items` is enabled. This flag is disabled by default, because the feature is experimental and is subject to change without notice. +Creates a work item. Available only when feature flag `work_items` is enabled. The feature is experimental and is subject to change without notice. Input type: `WorkItemCreateInput` diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md index f09f5ff0d60..4976f7c2664 100644 --- a/doc/integration/elasticsearch.md +++ b/doc/integration/elasticsearch.md @@ -473,7 +473,7 @@ The following are some available Rake tasks: | [`sudo gitlab-rake gitlab:elastic:index`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Enables Elasticsearch indexing and run `gitlab:elastic:create_empty_index`, `gitlab:elastic:clear_index_status`, `gitlab:elastic:index_projects`, and `gitlab:elastic:index_snippets`. | | [`sudo gitlab-rake gitlab:elastic:pause_indexing`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Pauses Elasticsearch indexing. Changes are still tracked. Useful for cluster/index migrations. | | [`sudo gitlab-rake gitlab:elastic:resume_indexing`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Resumes Elasticsearch indexing. | -| [`sudo gitlab-rake gitlab:elastic:index_projects`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Iterates over all projects and queues Sidekiq jobs to index them in the background. | +| [`sudo gitlab-rake gitlab:elastic:index_projects`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Iterates over all projects, and queues Sidekiq jobs to index them in the background. It can only be used after the index is created. | | [`sudo gitlab-rake gitlab:elastic:index_projects_status`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Determines the overall status of the indexing. It is done by counting the total number of indexed projects, dividing by a count of the total number of projects, then multiplying by 100. | | [`sudo gitlab-rake gitlab:elastic:clear_index_status`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Deletes all instances of IndexStatus for all projects. Note that this command results in a complete wipe of the index, and it should be used with caution. | | [`sudo gitlab-rake gitlab:elastic:create_empty_index`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/tasks/gitlab/elastic.rake) | Generates empty indexes (the default index and a separate issues index) and assigns an alias for each on the Elasticsearch side only if it doesn't already exist. | diff --git a/doc/user/clusters/migrating_from_gma_to_project_template.md b/doc/user/clusters/migrating_from_gma_to_project_template.md index 94e9d4af36a..b2ba1bef338 100644 --- a/doc/user/clusters/migrating_from_gma_to_project_template.md +++ b/doc/user/clusters/migrating_from_gma_to_project_template.md @@ -23,16 +23,16 @@ See also [video walk-throughs](#video-walk-throughs) with examples. 1. Create a new project based on the [Cluster Management Project template](management_project_template.md#create-a-new-project-based-on-the-cluster-management-template). 1. [Associate your new Cluster Management Project with your cluster](management_project.md#associate-the-cluster-management-project-with-the-cluster). 1. Detect apps deployed through Helm v2 releases by using the pre-configured [`.gitlab-ci.yml`](management_project_template.md#the-gitlab-ciyml-file) file: - - In case you had overwritten the default GitLab Managed Apps namespace, edit `.gitlab-ci.yml`, - and make sure the script is receiving the correct namespace as an argument: + - In case you had overwritten the default GitLab Managed Apps namespace, edit `.gitlab-ci.yml`, + and make sure the script is receiving the correct namespace as an argument: - ```yaml - script: - - gl-fail-if-helm2-releases-exist <your_custom_namespace> - ``` + ```yaml + script: + - gl-fail-if-helm2-releases-exist <your_custom_namespace> + ``` - - If you kept the default name (`gitlab-managed-apps`), then the script is already - set up. + - If you kept the default name (`gitlab-managed-apps`), then the script is already + set up. Either way, [run a pipeline manually](../../ci/pipelines/index.md#run-a-pipeline-manually) and read the logs of the `detect-helm2-releases` job to know if you have any Helm v2 releases and which are they. @@ -53,7 +53,7 @@ See also [video walk-throughs](#video-walk-throughs) with examples. ```shell helm ls -n gitlab-managed-apps - + NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION runner gitlab-managed-apps 1 2021-06-09 19:36:55.739141644 +0000 UTC deployed gitlab-runner-0.28.0 13.11.0 ``` @@ -67,42 +67,42 @@ See also [video walk-throughs](#video-walk-throughs) with examples. 1. Edit the `applications/{app}/values.yaml` associated with your app to match the currently deployed values. For example, for GitLab Runner: - 1. Copy the output of the following command (it might be big): + 1. Copy the output of the following command (it might be big): - ```shell - helm get values runner -n gitlab-managed-apps -a --output yaml - ``` + ```shell + helm get values runner -n gitlab-managed-apps -a --output yaml + ``` - 1. Overwrite `applications/gitlab-runner/values.yaml` with the output of the previous command. + 1. Overwrite `applications/gitlab-runner/values.yaml` with the output of the previous command. This safe step will guarantee that no unexpected default values overwrite your currently deployed values. For instance, your GitLab Runner could have its `gitlabUrl` or `runnerRegistrationToken` overwritten by mistake. 1. Some apps require special attention: - - Ingress: Due to an existing [chart issue](https://github.com/helm/charts/pull/13646), you might see - `spec.clusterIP: Invalid value` when trying to run the [`./gl-helmfile`](management_project_template.md#the-gitlab-ciyml-file) - command. To work around this, after overwriting the release values in `applications/ingress/values.yaml`, - you might need to overwrite all the occurrences of `omitClusterIP: false`, setting it to `omitClusterIP: true`. - Another approach,could be to collect these IPs by running `kubectl get services -n gitlab-managed-apps` - and then overwriting each `ClusterIP` that it complains about with the value you got from that command. - - - Vault: This application introduces a breaking change from the chart we used in Helm v2 to the chart - used in Helm v3. So, the only way to integrate it with this Cluster Management Project is to actually uninstall this app and accept the - chart version proposed in `applications/vault/values.yaml`. - - - Cert-manager: - - For users on Kubernetes version 1.20 or above, the deprecated cert-manager v0.10 is no longer valid - and the upgrade includes a breaking change. So we suggest that you [backup and uninstall cert-manager v0.10](#backup-and-uninstall-cert-manager-v010), - and install the latest cert-manager instead. To install this version, uncomment `applications/cert-manager/helmfile.yaml` - from [`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file). - This triggers a pipeline to install the new version. - - For users on Kubernetes versions lower than 1.20, you can stick to v0.10 by uncommenting - `applications/cert-manager-legacy/helmfile.yaml` - in your project's main Helmfile ([`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file)). - - WARNING: - Cert-manager v0.10 breaks when Kubernetes is upgraded to version 1.20 or later. + - Ingress: Due to an existing [chart issue](https://github.com/helm/charts/pull/13646), you might see + `spec.clusterIP: Invalid value` when trying to run the [`./gl-helmfile`](management_project_template.md#the-gitlab-ciyml-file) + command. To work around this, after overwriting the release values in `applications/ingress/values.yaml`, + you might need to overwrite all the occurrences of `omitClusterIP: false`, setting it to `omitClusterIP: true`. + Another approach,could be to collect these IPs by running `kubectl get services -n gitlab-managed-apps` + and then overwriting each `ClusterIP` that it complains about with the value you got from that command. + + - Vault: This application introduces a breaking change from the chart we used in Helm v2 to the chart + used in Helm v3. So, the only way to integrate it with this Cluster Management Project is to actually uninstall this app and accept the + chart version proposed in `applications/vault/values.yaml`. + + - Cert-manager: + - For users on Kubernetes version 1.20 or above, the deprecated cert-manager v0.10 is no longer valid + and the upgrade includes a breaking change. So we suggest that you [backup and uninstall cert-manager v0.10](#backup-and-uninstall-cert-manager-v010), + and install the latest cert-manager instead. To install this version, uncomment `applications/cert-manager/helmfile.yaml` + from [`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file). + This triggers a pipeline to install the new version. + - For users on Kubernetes versions lower than 1.20, you can stick to v0.10 by uncommenting + `applications/cert-manager-legacy/helmfile.yaml` + in your project's main Helmfile ([`./helmfile.yaml`](management_project_template.md#the-main-helmfileyml-file)). + + WARNING: + Cert-manager v0.10 breaks when Kubernetes is upgraded to version 1.20 or later. 1. After following all the previous steps, [run a pipeline manually](../../ci/pipelines/index.md#run-a-pipeline-manually) and watch the `apply` job logs to see if any of your applications were successfully detected, installed, and whether they got any @@ -121,7 +121,7 @@ you want to manage with the Cluster Management Project. ## Backup and uninstall cert-manager v0.10 1. Follow the [official docs](https://docs.cert-manager.io/en/release-0.10/tasks/backup-restore-crds.html) on how to - backup your cert-manager v0.10 data. + backup your cert-manager v0.10 data. 1. Uninstall cert-manager by editing the setting all the occurrences of `installed: true` to `installed: false` in the `applications/cert-manager/helmfile.yaml` file. 1. Search for any left-over resources by executing the following command `kubectl get Issuers,ClusterIssuers,Certificates,CertificateRequests,Orders,Challenges,Secrets,ConfigMaps -n gitlab-managed-apps | grep certmanager`. diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md index 641fc8a1509..f10dc3bc22a 100644 --- a/doc/user/group/roadmap/index.md +++ b/doc/user/group/roadmap/index.md @@ -85,8 +85,10 @@ When you enable the roadmap settings sidebar, you can use it to refine epics sho You can configure the following: - Select date range. +- Turn milestones on or off and select whether to show all, group, sub-group, or project milestones. - Show all, open, or closed epics. -- Turn progress tracking on or off and select whether it uses issue weights or counts. +- Turn progress tracking for child issues on or off and select whether + to use issue weights or counts. The progress tracking setting is not saved in user preferences but is saved or shared using URL parameters. diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md index 4663cfc8bfd..ccf77f79fd9 100644 --- a/doc/user/group/value_stream_analytics/index.md +++ b/doc/user/group/value_stream_analytics/index.md @@ -117,16 +117,15 @@ production environment for all merge requests deployed in the given time period. The "Recent Activity" metrics near the top of the page are measured as follows: - **New Issues:** the number of issues created in the date range. -- **Deploys:** the number of deployments <sup>1</sup> to production <sup>2</sup> in the date range. -- **Deployment Frequency:** the average number of deployments <sup>1</sup> to production <sup>2</sup> +- **Deploys:** the number of deployments to production in the date range. +- **Deployment Frequency:** the average number of deployments to production per day in the date range. -1. To give a more accurate representation of deployments that actually completed successfully, - the calculation for these two metrics changed in GitLab 13.9 from using the time a deployment was - created to the time a deployment finished. If you were referencing this metric prior to 13.9, please - keep this slight change in mind. -1. To see deployment metrics, you must have a - [production environment configured](../../../ci/environments/index.md#deployment-tier-of-environments). +To see deployment metrics, you must have a [production environment configured](../../../ci/environments/index.md#deployment-tier-of-environments). + +NOTE: +In GitLab 13.9 and later, deployment metrics are calculated based on when the deployment was finished. +In GitLab 13.8 and earlier, deployment metrics are calculated based on when the deployment was created. You can learn more about these metrics in our [analytics definitions](../../analytics/index.md). diff --git a/doc/user/project/import/bitbucket.md b/doc/user/project/import/bitbucket.md index 0c50fc77e33..62495872659 100644 --- a/doc/user/project/import/bitbucket.md +++ b/doc/user/project/import/bitbucket.md @@ -42,7 +42,7 @@ When issues/pull requests are being imported, the Bitbucket importer tries to fi the Bitbucket author/assignee in the GitLab database using the Bitbucket `nickname`. For this to work, the Bitbucket author/assignee should have signed in beforehand in GitLab and **associated their Bitbucket account**. Their `nickname` must also match their Bitbucket -`username.`. If the user is not found in the GitLab database, the project creator +`username`. If the user is not found in the GitLab database, the project creator (most of the times the current user that started the import process) is set as the author, but a reference on the issue about the original Bitbucket author is kept. diff --git a/doc/user/project/merge_requests/commits.md b/doc/user/project/merge_requests/commits.md index 8970f958603..0014c1ba994 100644 --- a/doc/user/project/merge_requests/commits.md +++ b/doc/user/project/merge_requests/commits.md @@ -29,21 +29,17 @@ To seamlessly navigate among commits in a merge request: ## View merge request commits in context -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29274) in GitLab 13.12. -> - [Deployed behind a feature flag](../../feature_flags.md), enabled by default. -> - Disabled on GitLab.com. -> - Not recommended for production use. -> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-viewing-merge-request-commits-in-context). +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29274) in GitLab 13.12 [with a flag](../../../administration/feature_flags.md) named `context_commits`. Enabled by default. +> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/320757) in GitLab 14.8. WARNING: This feature is in [beta](../../../policy/alpha-beta-support.md#beta-features) and is [incomplete](https://gitlab.com/groups/gitlab-org/-/epics/1192). -Previously merged commits can be added, but they can't be removed due to -[this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/325538). -This in-development feature might not be available for your use. There can be -[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development). -Refer to this feature's version history for more details. +FLAG: +On self-managed GitLab, by default this feature is available. To hide the feature, +ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `context_commits`. +On GitLab.com, this feature is available. When reviewing a merge request, it helps to have more context about the changes made. That includes unchanged lines in unchanged files, and previous commits @@ -66,22 +62,3 @@ To view the changes done on those previously merged commits: 1. Scroll to **(file-tree)** **Compare** and select **previously merged commits**: ![Previously merged commits](img/previously_merged_commits_v14_1.png) - -### Enable or disable viewing merge request commits in context **(FREE SELF)** - -Viewing merge request commits in context is under development and not ready for production use. It is -deployed behind a feature flag that is **disabled by default**. -[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) -can enable it. - -To enable it: - -```ruby -Feature.enable(:context_commits) -``` - -To disable it: - -```ruby -Feature.disable(:context_commits) -``` |