diff options
Diffstat (limited to 'doc/topics/autodevops/index.md')
| -rw-r--r-- | doc/topics/autodevops/index.md | 422 |
1 files changed, 177 insertions, 245 deletions
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index beb5f6a58f6..f4936e9162d 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -6,320 +6,269 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Auto DevOps **(FREE)** -> - Introduced in GitLab 11.0 for general availability. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38366) in GitLab 11.0. -GitLab Auto DevOps helps to reduce the complexity of software delivery by -setting up pipelines and integrations for you. Auto DevOps configures -GitLab CI/CD pipelines including security auditing and vulnerability -testing. +GitLab Auto DevOps is a collection of pre-configured features and integrations +that work together to support your software delivery process. -Using Auto DevOps, you can: +Auto DevOps features and integrations: -- Detect the language of your code. -- Automatically build, test, and measure code quality. -- Scan for potential vulnerabilities, security flaws, and licensing issues. -- Monitor in real-time. +- Detect your code's language. +- Build and test your application. +- Measure code quality. +- Scan for vulnerabilities and security flaws. +- Check for licensing issues. +- Monitor in real time. - Deploy your application. -The functionality of Auto DevOps is based on default CI/CD templates that -auto-discover your source code. These templates enable GitLab to provide -consistency across your projects, seamless management of processes, and faster -creation of new projects. Leveraging [CI/CD best practices](../../ci/pipelines/pipeline_efficiency.md) -and tools, Auto DevOps lets you push your code, with GitLab doing the rest, -improving your productivity and efficiency. - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> -For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4) or see this [overview](https://about.gitlab.com/stages-devops-lifecycle/auto-devops/). +For an introduction to Auto DevOps, watch [Auto DevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4). -For requirements, read [Requirements for Auto DevOps](requirements.md) for more information. +## Auto DevOps features -For GitLab contributors, see the [Auto DevOps development guide](../../development/auto_devops.md). +Based on the DevOps [stages](stages.md), use Auto DevOps to: -## Enable or disable Auto DevOps +**Build your app:** -Auto DevOps is enabled by default for all projects in self-managed instances -(as of [GitLab 11.3](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729)), -but not for GitLab SaaS instances. +- [Auto Build](stages.md#auto-build) +- [Auto Dependency Scanning](stages.md#auto-dependency-scanning) -When first using Auto DevOps, review the [requirements](requirements.md) to -ensure all the necessary components to make full use of Auto DevOps are -available. First-time users should follow the [quick start guide](quick_start_guide.md). +**Test your app:** -Depending on your instance type, you can enable or disable Auto DevOps at the -following levels: +- [Auto Test](stages.md#auto-test) +- [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing) +- [Auto Code Intelligence](stages.md#auto-code-intelligence) +- [Auto Code Quality](stages.md#auto-code-quality) +- [Auto Container Scanning](stages.md#auto-container-scanning) +- [Auto License Compliance](stages.md#auto-license-compliance) -| Instance type | [Project](#at-the-project-level) | [Group](#at-the-group-level) | [Instance](#at-the-instance-level) (Admin Area) | -|---------------------|------------------------|------------------------|------------------------| -| GitLab SaaS | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | -| GitLab self-managed | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | +**Deploy your app:** -When you enable Auto DevOps for your instance, it attempts to run on all -pipelines in each project. The Auto DevOps setting automatically disables itself for individual -projects on their first pipeline failure. An instance administrator can enable -or disable this default in the [Auto DevOps settings](../../user/admin_area/settings/continuous_integration.md#auto-devops). +- [Auto Review Apps](stages.md#auto-review-apps) +- [Auto Deploy](stages.md#auto-deploy) -[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) in GitLab 12.7, -Auto DevOps runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build) -exists. +**Monitor your app:** -If a [CI/CD configuration file](../../ci/yaml/index.md) is present in the -project, it remains unchanged and Auto DevOps doesn't affect it. +- [Auto Monitoring](stages.md#auto-monitoring) -### At the project level +**Secure your app:** -When you enable Auto DevOps for a project, ensure that your project does not have a `.gitlab-ci.yml` present. If it exists, remove it before enabling Auto DevOps. +- [Auto Dynamic Application Security Testing (DAST)](stages.md#auto-dast) +- [Auto Static Application Security Testing (SAST)](stages.md#auto-sast) +- [Auto Secret Detection](stages.md#auto-secret-detection) -To enable it: +### How it works -1. Go to your project's **Settings > CI/CD > Auto DevOps**. -1. Select the **Default to Auto DevOps pipeline** checkbox to enable it. -1. (Optional, but recommended) When enabling, you can add in the - [base domain](#auto-devops-base-domain) Auto DevOps uses to - [deploy your application](stages.md#auto-deploy), - and choose the [deployment strategy](#deployment-strategy). -1. Click **Save changes** for the changes to take effect. +Auto DevOps detects your code language and uses [CI/CD templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates) +to create and run default pipelines. All you need to kick it off is to +[enable](#enable-or-disable-auto-devops) it. -After enabling the feature, an Auto DevOps pipeline is triggered on the default branch. +Auto DevOps starts by building and testing your application. Then, based on your +[predefined deployment configuration](requirements.md), +creates the necessary jobs to deploy your apps to staging +and/or production. It also sets up [Review Apps](stages.md#auto-review-apps) +so that you can preview your changes in a per-branch basis. -### At the group level +Note that you don't need to set up the deployment upfront. Auto DevOps +still builds and tests your application. You can define the deployment later. -> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) in GitLab 11.10. +Auto DevOps avoids the hassle of having to create entire pipelines manually. +Keep it simple and facilitate an iterative approach: ship your app first, +then explore the [customizations](customize.md) later. +You can also [manage Auto DevOps with APIs](customize.md#extend-auto-devops-with-the-api). -Only administrators and group owners can enable or disable Auto DevOps at the group level. +Some of the benefits of using Auto DevOps as part of your workflow are: -When you enable Auto DevOps at group level, the subgroups and projects in that group inherit the configuration. Auto DevOps -can be specifically enabled or disabled individually for projects and subgroups. +- Consistency: always start from default templates. +- Simplicity: create your pipeline with the default settings first, iterate later. +- Productivity: deploy multiple apps in a short period of time. +- Efficiency: get things done fast. -To enable or disable Auto DevOps at the group level: +### Comparison to application platforms and PaaS -1. Go to your group's **Settings > CI/CD > Auto DevOps** page. -1. Select the **Default to Auto DevOps pipeline** checkbox to enable it. -1. Click **Save changes** for the changes to take effect. +Auto DevOps provides features often included in an application +platform or in a Platform as a Service (PaaS). -### At the instance level **(FREE SELF)** +Inspired by [Heroku](https://www.heroku.com/), Auto DevOps goes beyond it +in multiple ways: -Even when disabled at the instance level, group owners and project maintainers -can still enable Auto DevOps at the group and project level, respectively. +- Auto DevOps works with any Kubernetes cluster. +- There is no additional cost. +- You can use a cluster hosted by yourself or on any public cloud. +- Auto DevOps offers an incremental graduation path. If you need to [customize](customize.md), start by changing the templates and evolve from there. -1. As an administrator, on the top bar, select **Menu >** **{admin}** **Admin**. -1. Go to **Settings > CI/CD > Continuous Integration and Deployment**. -1. Select **Default to Auto DevOps pipeline for all projects** to enable it. -1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain), - for Auto Deploy and Auto Review Apps to use. -1. Click **Save changes** for the changes to take effect. +## Get started with Auto DevOps -### Deployment strategy +To get started, you only need to [enable Auto DevOps](#enable-or-disable-auto-devops). +This is enough to run an Auto DevOps pipeline to build and +test your application. -> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0. +If you want to build, test, and deploy your app: -You can change the deployment strategy used by Auto DevOps by visiting your -project's **Settings > CI/CD > Auto DevOps**. The following options -are available: +1. See the [requirements for deployment](requirements.md). +1. [Enable Auto DevOps](#enable-or-disable-auto-devops). +1. Follow the [quick start guide](#quick-start). -- **Continuous deployment to production**: Enables [Auto Deploy](stages.md#auto-deploy) - with the default branch directly deployed to production. -- **Continuous deployment to production using timed incremental rollout**: Sets the - [`INCREMENTAL_ROLLOUT_MODE`](customize.md#timed-incremental-rollout-to-production) variable - to `timed`. Production deployments execute with a 5 minute delay between - each increment in rollout. -- **Automatic deployment to staging, manual deployment to production**: Sets the - [`STAGING_ENABLED`](customize.md#deploy-policy-for-staging-and-production-environments) and - [`INCREMENTAL_ROLLOUT_MODE`](customize.md#incremental-rollout-to-production) variables - to `1` and `manual`. This means: +As Auto DevOps relies on many components, be familiar with: - - The default branch is directly deployed to staging. - - Manual actions are provided for incremental rollout to production. +- [Continuous methodologies](../../ci/introduction/index.md) +- [Docker](https://docs.docker.com) +- [GitLab Runner](https://docs.gitlab.com/runner/) -NOTE: -Use the [blue-green deployment](../../ci/environments/incremental_rollouts.md#blue-green-deployment) technique -to minimize downtime and risk. +When deploying to a Kubernetes cluster make sure you're also familiar with: -## Quick start +- [Kubernetes](https://kubernetes.io/docs/home/) +- [Helm](https://helm.sh/docs/) +- [Prometheus](https://prometheus.io/docs/introduction/overview/) -For GitLab.com users, see the [quick start guide](quick_start_guide.md) -for setting up Auto DevOps deploying to a Kubernetes cluster on Google Kubernetes -Engine (GKE). +### Enable or disable Auto DevOps -If you use a self-managed instance of GitLab, you must configure the -[Google OAuth 2.0 OmniAuth Provider](../../integration/google.md) before -configuring a cluster on GKE. After configuring the provider, you can follow -the steps in the [quick start guide](quick_start_guide.md) to get started. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3, Auto DevOps is enabled by default. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) GitLab 12.7, Auto DevOps runs pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build) exists. -In [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) and later, it is -possible to leverage Auto DevOps to deploy to [AWS ECS](requirements.md#auto-devops-requirements-for-amazon-ecs). +Depending on your instance type, you can enable or disable Auto DevOps at the +following levels: -## Comparison to application platforms and PaaS +| Instance type | [Project](#at-the-project-level) | [Group](#at-the-group-level) | [Instance](#at-the-instance-level) (Admin Area) | +|---------------------|------------------------|------------------------|------------------------| +| GitLab SaaS | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | +| GitLab self-managed | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | -Auto DevOps provides features often included in an application -platform or a Platform as a Service (PaaS). It takes inspiration from the -innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it -in multiple ways: +Before enabling Auto DevOps, consider [preparing it for deployment](requirements.md). If you don't, Auto DevOps can build and test your app, +but cannot deploy it. -- Auto DevOps works with any Kubernetes cluster; you're not limited to running - on infrastructure managed by GitLab. (Note that many features also work without Kubernetes). -- There is no additional cost (no markup on the infrastructure costs), and you - can use a Kubernetes cluster you host or Containers as a Service on any - public cloud (for example, [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)). -- Auto DevOps has more features including security testing, performance testing, - and code quality testing. -- Auto DevOps offers an incremental graduation path. If you need advanced customizations, - you can start modifying the templates without starting over on a - completely different platform. Review the [customizing](customize.md) documentation for more information. +#### At the project level -## Features +To use Auto DevOps for individual projects, you can enable it in a +project-by-project basis. If you intend to use it for more projects, +you can enable it for a [group](#at-the-group-level) or an +[instance](#at-the-instance-level). This can save you the time of +enabling it one by one. -NOTE: -Depending on your target platform, some features might not be available to you. +Only project Maintainers can enable or disable Auto DevOps at the project level. -Comprised of a set of [stages](stages.md), Auto DevOps brings these best practices to your -project automatically: +Before enabling Auto DevOps, ensure that your project does not have a +`.gitlab-ci.yml` present. If present, your CI/CD configuration takes +precedence over the Auto DevOps pipeline. -- [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing) -- [Auto Build](stages.md#auto-build) -- [Auto Code Intelligence](stages.md#auto-code-intelligence) -- [Auto Code Quality](stages.md#auto-code-quality) -- [Auto Container Scanning](stages.md#auto-container-scanning) -- [Auto DAST (Dynamic Application Security Testing)](stages.md#auto-dast) -- [Auto Dependency Scanning](stages.md#auto-dependency-scanning) -- [Auto Deploy](stages.md#auto-deploy) -- [Auto License Compliance](stages.md#auto-license-compliance) -- [Auto Monitoring](stages.md#auto-monitoring) -- [Auto Review Apps](stages.md#auto-review-apps) -- [Auto SAST (Static Application Security Testing)](stages.md#auto-sast) -- [Auto Secret Detection](stages.md#auto-secret-detection) -- [Auto Test](stages.md#auto-test) +To enable Auto DevOps for a project: -As Auto DevOps relies on many different components, you should have a basic -knowledge of the following: +1. Go to your project's **Settings > CI/CD > Auto DevOps**. +1. Select the **Default to Auto DevOps pipeline**. +1. (Recommended) Add the [base domain](requirements.md#auto-devops-base-domain). +1. (Recommended) Choose the [deployment strategy](requirements.md#auto-devops-deployment-strategy). +1. Select **Save changes**. -- [Kubernetes](https://kubernetes.io/docs/home/) -- [Helm](https://helm.sh/docs/) -- [Docker](https://docs.docker.com) -- [GitLab Runner](https://docs.gitlab.com/runner/) -- [Prometheus](https://prometheus.io/docs/introduction/overview/) +GitLab triggers the Auto DevOps pipeline on the default branch. -Auto DevOps provides great defaults for all the stages and makes use of -[CI templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates). You can, however, -[customize](customize.md) almost everything to your needs, and -[manage Auto DevOps with GitLab APIs](customize.md#extend-auto-devops-with-the-api). +To disable it, follow the same process and deselect **Default to Auto +DevOps pipeline**. -For an overview on the creation of Auto DevOps, read more -[in this blog post](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/). +#### At the group level -NOTE: -Kubernetes clusters can [be used without](../../user/project/clusters/index.md) -Auto DevOps. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) in GitLab 11.10. -## Kubernetes requirements +When you enable Auto DevOps at group level, the subgroups and projects in that +group inherit the configuration. This saves you time by batch-enabling it +rather than enabling individually for each subgroup or project. -See [Auto DevOps requirements for Kubernetes](requirements.md#auto-devops-requirements-for-kubernetes). +When enabled for a group, you can still disable Auto DevOps +for the subgroups and projects where you don't want to use it. -## Auto DevOps base domain +Only GitLab administrators and group owners can enable or disable Auto DevOps +at the group level. -The Auto DevOps base domain is required to use -[Auto Review Apps](stages.md#auto-review-apps), [Auto Deploy](stages.md#auto-deploy), and -[Auto Monitoring](stages.md#auto-monitoring). You can define the base domain in -any of the following places: +To enable Auto DevOps for a group: -- Either under the cluster's settings, whether for an instance, - [projects](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) or - [groups](../../user/group/clusters/index.md#base-domain) -- Or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN` -- Or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN` -- Or as an instance-wide fallback in **Menu >** **{admin}** **Admin >** - **Settings > CI/CD** under the **Continuous Integration and Delivery** section. +1. Go to your group's **Settings > CI/CD > Auto DevOps**. +1. Select **Default to Auto DevOps pipeline**. +1. Select **Save changes**. -The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence -as other environment [variables](../../ci/variables/index.md#cicd-variable-precedence). -If this variable isn't set and the cluster setting is left blank, the instance-wide domain is used if set for your instance. +After enabling Auto DevOps at the group level, you can trigger the +Auto DevOps pipeline for any project that belongs to that group. To do so: -Auto DevOps requires a wildcard DNS A record matching the base domain(s). For -a base domain of `example.com`, you'd need a DNS entry like: +1. Go to the project's homepage. +1. Make sure the project doesn't contain a `.gitlab-ci.yml` file. +1. From the project's sidebar, go to **CI/CD > Pipelines**. +1. Select **Run pipeline** to trigger the Auto DevOps pipeline. -```plaintext -*.example.com 3600 A 1.2.3.4 -``` +To disable Auto DevOps on the group level, follow the same process and +deselect **Default to Auto DevOps pipeline**. -In this case, the deployed applications are served from `example.com`, and `1.2.3.4` -is the IP address of your load balancer; generally NGINX ([see requirements](requirements.md)). -Setting up the DNS record is beyond the scope of this document; check with your -DNS provider for information. +#### At the instance level **(FREE SELF)** -Alternatively, you can use free public services like [nip.io](https://nip.io) -which provide automatic wildcard DNS without any configuration. For [nip.io](https://nip.io), -set the Auto DevOps base domain to `1.2.3.4.nip.io`. +By enabling Auto DevOps in the instance level, all projects created in that +instance become enabled. This is convenient when you want to run Auto DevOps by +default for all projects. You can still disable Auto DevOps individually for +the groups and projects where you don't want to run it. -After completing setup, all requests hit the load balancer, which routes requests -to the Kubernetes pods running your application. +Only GitLab administrators can enable or disable Auto DevOps in the instance +level. -### AWS ECS +Even when disabled for an instance, group owners and project maintainers +can still enable Auto DevOps at the group and project levels. -See [Auto DevOps requirements for Amazon ECS](requirements.md#auto-devops-requirements-for-amazon-ecs). +To enable Auto DevOps for your instance: -## Use multiple Kubernetes clusters +1. From the top bar, select **Menu >** **{admin}** **Admin**. +1. Go to **Settings > CI/CD > Continuous Integration and Deployment**. +1. Select **Default to Auto DevOps pipeline**. +1. (Optional) Add the Auto DevOps [base domain](requirements.md#auto-devops-base-domain). +1. Select **Save changes**. -When using Auto DevOps, you can deploy different environments to -different Kubernetes clusters, due to the 1:1 connection -[existing between them](../../user/project/clusters/multiple_kubernetes_clusters.md). +When enabled, it attempts to run Auto DevOps pipelines in every project. If the +pipeline fails in a particular project, it disables itself. +GitLab administrators can change this in the [Auto DevOps settings](../../user/admin_area/settings/continuous_integration.md#auto-devops). -The [Deploy Job template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) -used by Auto DevOps defines 3 environment names: +If a [CI/CD configuration file](../../ci/yaml/index.md) is present, +it remains unchanged and Auto DevOps doesn't affect it. -- `review/` (every environment starting with `review/`) -- `staging` -- `production` +To disable Auto DevOps in the instance level, follow the same process +and deselect the **Default to Auto DevOps pipeline** checkbox. -Those environments are tied to jobs using [Auto Deploy](stages.md#auto-deploy), so -except for the environment scope, they must have a different deployment domain. -You must define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for each of the above -[based on the environment](../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable). +### Quick start -The following table is an example of how to configure the three different clusters: +To guide your through the process of setting up Auto DevOps to deploy to a Kubernetes cluster on +Google Kubernetes Engine (GKE), see the [quick start guide](quick_start_guide.md). -| Cluster name | Cluster environment scope | `KUBE_INGRESS_BASE_DOMAIN` variable value | Variable environment scope | Notes | -|--------------|---------------------------|-------------------------------------------|----------------------------|---| -| review | `review/*` | `review.example.com` | `review/*` | The review cluster which runs all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, used by every environment name starting with `review/`. | -| staging | `staging` | `staging.example.com` | `staging` | (Optional) The staging cluster which runs the deployments of the staging environments. You must [enable it first](customize.md#deploy-policy-for-staging-and-production-environments). | -| production | `production` | `example.com` | `production` | The production cluster which runs the production environment deployments. You can use [incremental rollouts](customize.md#incremental-rollout-to-production). | +You can also follow the quick start for the general steps, but deploy to +[AWS ECS](requirements.md#auto-devops-requirements-for-amazon-ecs) instead. -To add a different cluster for each environment: +If you're a self-managed user, before deploying to GKE, a GitLab administrator needs to: -1. Navigate to your project's **Infrastructure > Kubernetes clusters**. -1. Create the Kubernetes clusters with their respective environment scope, as - described from the table above. -1. After creating the clusters, navigate to each cluster and [install - Ingress](quick_start_guide.md#install-ingress). Wait for the Ingress IP address to be assigned. -1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the - specified Auto DevOps domains. -1. Navigate to each cluster's page, through **Infrastructure > Kubernetes clusters**, - and add the domain based on its Ingress IP address. +1. Configure the [Google OAuth 2.0 OmniAuth Provider](../../integration/google.md). +1. Configure a cluster on GKE. -After completing configuration, test your setup by creating a merge request. -Verify whether your application deployed as a Review App in the Kubernetes -cluster with the `review/*` environment scope. Similarly, you can check the -other environments. +## Upgrade Auto DevOps dependencies when updating GitLab -[Cluster environment scope isn't respected](https://gitlab.com/gitlab-org/gitlab/-/issues/20351) -when checking for active Kubernetes clusters. For multi-cluster setup to work with Auto DevOps, -create a fallback cluster with **Cluster environment scope** set to `*`. A new cluster isn't -required. You can use any of the clusters already added. +When updating GitLab, you may need to upgrade Auto DevOps dependencies to +match your new GitLab version: -## Limitations +- [Upgrading Auto DevOps resources](upgrading_auto_deploy_dependencies.md): + - Auto DevOps template. + - Auto Deploy template. + - Auto Deploy image. + - Helm. + - Kubernetes. + - Environment variables. +- [Upgrading PostgreSQL](upgrading_postgresql.md). -The following restrictions apply. +## Limitations ### Private registry support -No documented way of using private container registry with Auto DevOps exists. -We strongly advise using GitLab Container Registry with Auto DevOps to +We cannot guarantee that you can use a private container registry with Auto DevOps. + +We strongly advise you to use GitLab Container Registry with Auto DevOps to simplify configuration and prevent any unforeseen issues. ### Install applications behind a proxy The GitLab integration with Helm does not support installing applications when -behind a proxy. Users who want to do so must inject their proxy settings -into the installation pods at runtime, such as by using a -[`PodPreset`](https://v1-19.docs.kubernetes.io/docs/concepts/workloads/pods/podpreset/): +behind a proxy. + +To do so, inject proxy settings into the installation pods at runtime. +For example, you can use a [`PodPreset`](https://v1-19.docs.kubernetes.io/docs/concepts/workloads/pods/podpreset/): ```yaml apiVersion: settings.k8s.io/v1alpha1 @@ -335,23 +284,6 @@ spec: value: "PUT_YOUR_HTTPS_PROXY_HERE" ``` -## Upgrade Auto DevOps dependencies when updating GitLab - -When updating GitLab, you may need to upgrade Auto DevOps dependencies to -match your new GitLab version: - -- [Upgrading Auto DevOps resources](upgrading_auto_deploy_dependencies.md): - - Auto DevOps template. - - Auto Deploy template. - - Auto Deploy image. - - Helm. - - Kubernetes. - - Environment variables. -- [Upgrading PostgreSQL](upgrading_postgresql.md). - ## Troubleshooting See [troubleshooting Auto DevOps](troubleshooting.md). - -<!-- DO NOT ADD TROUBLESHOOTING INFO HERE --> -<!-- Troubleshooting information has moved to troubleshooting.md --> |