diff options
Diffstat (limited to 'doc/topics')
-rw-r--r-- | doc/topics/authentication/index.md | 2 | ||||
-rw-r--r-- | doc/topics/autodevops/customize.md | 6 | ||||
-rw-r--r-- | doc/topics/cron/index.md | 2 | ||||
-rw-r--r-- | doc/topics/git/lfs/index.md | 2 | ||||
-rw-r--r-- | doc/topics/git/lfs/migrate_to_git_lfs.md | 2 | ||||
-rw-r--r-- | doc/topics/git/merge_conflicts.md | 2 | ||||
-rw-r--r-- | doc/topics/gitlab_flow.md | 8 | ||||
-rw-r--r-- | doc/topics/release_your_application.md | 6 |
8 files changed, 17 insertions, 13 deletions
diff --git a/doc/topics/authentication/index.md b/doc/topics/authentication/index.md index 2a301e6ff5b..9ab6235164a 100644 --- a/doc/topics/authentication/index.md +++ b/doc/topics/authentication/index.md @@ -1,6 +1,6 @@ --- stage: Manage -group: Authentication & Authorization +group: Authentication and Authorization info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index 177e10b99b9..089f9f8e7cc 100644 --- a/doc/topics/autodevops/customize.md +++ b/doc/topics/autodevops/customize.md @@ -190,6 +190,9 @@ You can override the default values in the `values.yaml` file in the `HELM_UPGRADE_VALUES_FILE` [CI/CD variable](#cicd-variables) with the path and name. +Some values can not be overridden with the options above. Settings like `replicaCount` should instead be overridden with the `REPLICAS` +[build and deployment](#build-and-deployment) CI/CD variable. Follow [this issue](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/issues/31) for more information. + NOTE: For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` variable to override the default chart values by setting `HELM_UPGRADE_EXTRA_ARGS` to `--values <my-values.yaml>`. @@ -433,7 +436,7 @@ applications. | `KUBE_NAMESPACE` | The namespace used for deployments. When using certificate-based clusters, [this value should not be overwritten directly](../../user/project/clusters/deploy_to_cluster.md#custom-namespace). | | `KUBECONFIG` | The kubeconfig to use for deployments. User-provided values take priority over GitLab-provided values. | | `PRODUCTION_REPLICAS` | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. | -| `REPLICAS` | Number of replicas to deploy. Defaults to 1. | +| `REPLICAS` | Number of replicas to deploy. Defaults to 1. Change this variable instead of [modifying](#customize-values-for-helm-chart) `replicaCount`. | | `ROLLOUT_RESOURCE_TYPE` | Allows specification of the resource type being deployed when using a custom Helm chart. Default value is `deployment`. | | `ROLLOUT_STATUS_DISABLED` | From GitLab 12.0, used to disable rollout status check because it does not support all resource types, for example, `cronjob`. | | `STAGING_ENABLED` | Used to define a [deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments). | @@ -478,6 +481,7 @@ The following table lists variables used to disable jobs. | `brakeman-sast` | `SAST_DISABLED` | | If the variable is present, the job isn't created. | | `bundler-audit-dependency_scanning` | `DEPENDENCY_SCANNING_DISABLED` | | If the variable is present, the job isn't created. | | `canary` | `CANARY_ENABLED` | | This manual job is created if the variable is present. | +| `cluster_image_scanning` | `CLUSTER_IMAGE_SCANNING_DISABLED` | | If the variable is present, the job isn't created. | | `code_intelligence` | `CODE_INTELLIGENCE_DISABLED` | From GitLab 13.6 | If the variable is present, the job isn't created. | | `code_quality` | `CODE_QUALITY_DISABLED` | | If the variable is present, the job isn't created. | | `container_scanning` | `CONTAINER_SCANNING_DISABLED` | | If the variable is present, the job isn't created. | diff --git a/doc/topics/cron/index.md b/doc/topics/cron/index.md index de83ec8b51b..affd746f66f 100644 --- a/doc/topics/cron/index.md +++ b/doc/topics/cron/index.md @@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w Cron syntax is used to schedule when jobs should run. You may need to use a cron syntax string to -create a [pipeline schedule](../../api/pipeline_schedules.md#create-a-new-pipeline-schedule), +create a [pipeline schedule](../../ci/pipelines/schedules.md), or to prevent unintentional releases by setting a [deploy freeze](../../user/project/releases/index.md#prevent-unintentional-releases-by-setting-a-deploy-freeze). diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md index a94caf2bf33..977f51a7211 100644 --- a/doc/topics/git/lfs/index.md +++ b/doc/topics/git/lfs/index.md @@ -31,7 +31,7 @@ Documentation for GitLab instance administrators is under [LFS administration do - Git LFS is supported in GitLab starting with version 8.2 - Git LFS must be enabled under project settings -- [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up +- [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up must be installed ## Known limitations diff --git a/doc/topics/git/lfs/migrate_to_git_lfs.md b/doc/topics/git/lfs/migrate_to_git_lfs.md index 2786368a9d7..32e3b6e2f72 100644 --- a/doc/topics/git/lfs/migrate_to_git_lfs.md +++ b/doc/topics/git/lfs/migrate_to_git_lfs.md @@ -46,7 +46,7 @@ Before beginning, make sure: To follow this tutorial, you need: -- The [Maintainer role](../../../user/permissions.md) for the existing Git repository +- The Maintainer role for the existing Git repository you'd like to migrate to LFS with access through the command line. - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [Java Runtime Environment](https://www.java.com/en/download/manual.jsp) diff --git a/doc/topics/git/merge_conflicts.md b/doc/topics/git/merge_conflicts.md index bf69190030c..47276ccb0b2 100644 --- a/doc/topics/git/merge_conflicts.md +++ b/doc/topics/git/merge_conflicts.md @@ -23,7 +23,7 @@ comments: false 1. Fix conflicts on the `conflicts.rb` file. 1. Stage the file and continue rebasing. 1. Force push the changes. -1. Finally continue with the Merge Request. +1. Finally continue with the merge request. ```shell git checkout -b conflicts_branch diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index 7675bba8d83..3bca33b32b7 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -71,7 +71,7 @@ For example, many projects do releases but don't need to do hotfixes. ## GitHub flow as a simpler alternative In reaction to Git flow, GitHub created a simpler alternative. -[GitHub flow](https://guides.github.com/introduction/flow/index.html) has only feature branches and a `main` branch: +[GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) has only feature branches and a `main` branch: ```mermaid graph TD @@ -221,7 +221,7 @@ If the assigned person does not feel comfortable, they can request more changes In GitLab, it is common to protect the long-lived branches, such as the `main` branch, so [most developers can't modify them](../user/permissions.md). So, if you want to merge into a protected branch, assign your merge request to someone with the -[Maintainer role](../user/permissions.md). +Maintainer role. After you merge a feature branch, you should remove it from the source control software. In GitLab, you can do this when merging. @@ -341,7 +341,7 @@ However, as discussed in [the section about rebasing](#squashing-commits-with-re Rebasing could create more work, as every time you rebase, you may need to resolve the same conflicts. Sometimes you can reuse recorded resolutions (`rerere`), but merging is better, because you only have to resolve conflicts once. -Atlassian has a more thorough explanation of the tradeoffs between merging and rebasing [on their blog](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase). +Atlassian has [a more thorough explanation of the tradeoffs between merging and rebasing](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase) on their blog. A good way to prevent creating many merge commits is to not frequently merge `main` into the feature branch. There are three reasons to merge in `main`: utilizing new code, resolving merge conflicts, and updating long-running branches. @@ -403,7 +403,7 @@ git commit -m 'Properly escape special characters in XML generation' An example of a good commit message is: "Combine templates to reduce duplicate code in the user views." The words "change," "improve," "fix," and "refactor" don't add much information to a commit message. -For more information about formatting commit messages, please see this excellent [blog post by Tim Pope](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). +For more information, please see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). To add more context to a commit message, consider adding information regarding the origin of the change. For example, the URL of a GitLab issue, or a Jira issue number, diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md index 3a0080fe21c..64decba33ad 100644 --- a/doc/topics/release_your_application.md +++ b/doc/topics/release_your_application.md @@ -30,8 +30,8 @@ to Kubernetes clusters using the [GitLab Agent](../user/clusters/agent/install/i #### GitOps deployments **(PREMIUM)** -With the [GitLab Agent](../user/clusters/agent/install/index.md), you can perform pull-based -deployments using Kubernetes manifests. This provides a scalable, secure, and cloud-native +With the [GitLab Agent](../user/clusters/agent/install/index.md), you can perform [pull-based +deployments of Kubernetes manifests](../user/clusters/agent/repository.md#synchronize-manifest-projects). This provides a scalable, secure, and cloud-native approach to manage Kubernetes deployments. #### Deploy to Kubernetes with the CI/CD Tunnel @@ -63,4 +63,4 @@ Use GitLab [Releases](../user/project/releases/index.md) to plan, build, and del ### Feature flags -Use [feature flags](../operations/feature_flags.md) to control and strategically roullout application deployments. +Use [feature flags](../operations/feature_flags.md) to control and strategically rollout application deployments. |