### Description We want to enable CI/CD for all projects, so everyone can enjoy the benefits of common best practices such as CI tests, code quality, review apps, etc. We've discussed several ways to do this, but the one that keeps coming up is an "implied" `.gitlab-ci.yml` where all projects which have CI/CD enabled will use the implied configuration, if they don't have one themselves. The implied configuration cannot be controlled or changed by anyone, and it is vendored at instance level. If someone wants to customize it, the exact same `.gitlab-ci.yml` will be available also as a template that can be applied to the project and then modified. The first iteration will not enable this configuration by default, but will make very easy to discover (with a banner when convenient) and enable it using a project setting. This issue covers only aspects regarding the "infrastructure" for having Auto DevOps integrated into the product, and the user workflow and experience. **Note**: in #37115 there is the global plan for the first iteration. ### Proposal This is the list of minimal implementation for integration of Auto DevOps in the workflow. - Auto DevOps works by using a `.gitlab-ci.yml` that is also available as a template (vendored, no changes) - Automatic configuration will not be enabled by default instance-wide - A project setting will allow to turn it on/off on single project - If Auto DevOps is on, it works by using the vendored `.gitlab-ci.yml` only if an existing (or equivalent) doesn't exist in the specific branch - Add a banner asking if you want to enable Auto for specific project: #37158 **Note**: when referencing to existing `.gitlab-ci.yml`, it is intended that we need to consider the project's settings that can alter the path of the configuration file #### Possibly deferred iteration (but would be nice to get into first iteration) - An application option will allow to turn it on/off instance-wide (is it needed anymore?) - It can be possible to enable it during installation (omnibus, helm), if we have application setting - Add button to view implied CI/CD configuration - In configuration view, add button to edit CI/CD configuration, which would prep a file addition, with the implied `.gitlab-ci.yml` as the starting point. - Add a banner asking if you want to enable Auto DevOps when an Admin logs in; #37002 - Add a banner to notice you need Kubernetes configured to have Auto Deploy working #### Possibly deferred iteration (but would be nice to get into first iteration) * Auto Deploy => Auto DevOps * Deprecate Auto Deploy template * Remove "Set up Auto Deploy" button ### Links / references * Auto DevOps (Beta) (#37115) * `.gitlab-ci.yml` used by Auto DevOps (#36870) * Similar to https://gitlab.com/gitlab-org/gitlab-ee/issues/2708, but much broader * Depends on https://gitlab.com/gitlab-org/gitlab-ce/issues/34785 * Works better with https://gitlab.com/gitlab-org/gitlab-ce/issues/26941 * Related: https://gitlab.com/gitlab-org/gitlab-ce/issues/34102 * Group-level Kubernetes service: https://gitlab.com/gitlab-org/gitlab-ce/issues/34758 * Group secret variables: https://gitlab.com/gitlab-org/gitlab-ce/issues/12729 * Part of: Auto DevOps: https://gitlab.com/gitlab-org/gitlab-ce/issues/35712 ### Feature checklist Make sure these are completed before closing the issue, with a link to the relevant commit. - [ ] [Feature assurance](https://about.gitlab.com/handbook/product/#feature-assurance) - [ ] Documentation - [ ] Added to [features.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml) ### Design __Project ci/cd settings:__ - Support switching back to default managed - Default managed radio button will be selected by default - Default managed radio button description will show the current instance wide feature status  __Pipeline list:__ - Put a tag in the pipeline row, if it uses auto devops .gitlab-ci.yml:  - Tooltip on auto devops tag:  __Admin settings:__ - Adjust section title to feature "Continuous Integration and Deployment" - Add option and description, with link to docs