Integrate usage of an implicit .gitlab-ci.yml for Auto DevOps
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 (closed) 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 (closed)
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 (moved)
- 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 (closed))
-
.gitlab-ci.yml
used by Auto DevOps (#36870 (closed)) - 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 -
Documentation -
Added to 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