AutoDevOps should not run when no Kubernetes cluster is configured

Summary

The new release enabled the autodevops feature by default, even when no Kubernetes Cluster is configured. This leads to a merge request which cannot be merged because the internal pipeline failed.

Alternative: Feature: You should be able to remove a pipeline from an existing Merge Request when AutoDevops is disabled after Merge Request is opened.

Steps to reproduce

• Clean gitlab installation with no auto devops configured
• Create project
• Pipeline needs to run successfully when create a merge request
• Integrate an external pipeline (in example jenkins)
• Create a Merge Request
• Merge Request cannot be merged because no runner for autodevops is available

What is the current bug behavior?

Merge Request cannot be merged because autodevops pipeline failes

What is the expected correct behavior?

AutoDevops should not run when not configurred

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.4.4p296
Gem Version:	2.7.6
Bundler Version:1.16.2
Rake Version:	12.3.1
Redis Version:	3.2.11
Git Version:	2.18.1
Sidekiq Version:5.1.3
Go Version:	unknown
GitLab information
Version:	11.3.5-ee
Revision:	7b10203
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
DB Version:	9.6.8
URL:		https://scm.mikatiming.net
HTTP Clone URL:	https://scm.mikatiming.net/some-group/some-project.git
SSH Clone URL:	git@scm.mikatiming.net:some-group/some-project.git
Elasticsearch:	yes
Geo:		no
Using LDAP:	yes
Using Omniauth:	yes
Omniauth Providers: bitbucket
GitLab Shell
Version:	8.3.3
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

Checking GitLab Shell ...
GitLab Shell version >= 8.3.3 ? ... OK (8.3.3)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
3/5 ... ok
2/6 ... ok
5/7 ... ok
16/8 ... repository is empty
19/9 ... ok
19/10 ... repository is empty
20/11 ... ok
15/18 ... ok
15/19 ... ok
16/21 ... ok
7/22 ... ok
7/23 ... ok
7/24 ... ok
7/25 ... ok
7/26 ... ok
7/27 ... ok
7/28 ... ok
7/29 ... ok
7/30 ... ok
8/32 ... ok
25/33 ... ok
9/34 ... ok
14/35 ... ok
10/37 ... ok
30/38 ... ok
8/39 ... ok
8/40 ... ok
8/41 ... ok
8/42 ... ok
5/44 ... ok
3/46 ... ok
16/48 ... ok
15/49 ... ok
32/50 ... ok
4/52 ... ok
4/53 ... ok
10/55 ... ok
33/56 ... ok
34/57 ... ok
34/58 ... ok
12/60 ... ok
12/61 ... ok
14/62 ... ok
35/63 ... ok
3/64 ... ok
9/65 ... ok
9/66 ... ok
9/67 ... ok
5/69 ... ok
15/71 ... ok
10/72 ... ok
30/73 ... ok
9/74 ... ok
9/75 ... ok
33/77 ... ok
9/78 ... ok
38/80 ... ok
22/81 ... ok
20/82 ... ok
9/84 ... ok
39/88 ... ok
15/91 ... ok
27/92 ... ok
26/93 ... ok
40/94 ... ok
9/95 ... ok
9/96 ... ok
41/98 ... ok
41/100 ... ok
24/103 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking LDAP ...
Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
-- data privacy --
Checking LDAP ... Finished
Checking GitLab ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
3/5 ... yes
2/6 ... yes
5/7 ... yes
16/8 ... yes
19/9 ... yes
19/10 ... yes
20/11 ... yes
15/18 ... yes
15/19 ... yes
16/21 ... yes
7/22 ... yes
7/23 ... yes
7/24 ... yes
7/25 ... yes
7/26 ... yes
7/27 ... yes
7/28 ... yes
7/29 ... yes
7/30 ... yes
8/32 ... yes
25/33 ... yes
9/34 ... yes
14/35 ... yes
10/37 ... yes
30/38 ... yes
8/39 ... yes
8/40 ... yes
8/41 ... yes
8/42 ... yes
5/44 ... yes
3/46 ... yes
16/48 ... yes
15/49 ... yes
32/50 ... yes
4/52 ... yes
4/53 ... yes
10/55 ... yes
33/56 ... yes
34/57 ... yes
34/58 ... yes
12/60 ... yes
12/61 ... yes
14/62 ... yes
35/63 ... yes
3/64 ... yes
9/65 ... yes
9/66 ... yes
9/67 ... yes
5/69 ... yes
15/71 ... yes
10/72 ... yes
30/73 ... yes
9/74 ... yes
9/75 ... yes
33/77 ... yes
9/78 ... yes
38/80 ... yes
22/81 ... yes
20/82 ... yes
9/84 ... yes
39/88 ... yes
15/91 ... yes
27/92 ... yes
26/93 ... yes
40/94 ... yes
9/95 ... yes
9/96 ... yes
41/98 ... yes
41/100 ... yes
24/103 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.4)
Git version >= 2.9.5 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 18
Elasticsearch version 5.1 - 5.5? ... no (6.2.4)
For more information see:
doc/integration/elasticsearch.md
Checking GitLab ... Finished

changed the description

added devopsverify label

/cc: @jlenny

I think this is actually @danielgruesso

Thanks for the issue @H3npi. Actually even with no cluster there are many stages that could be advantageous, such as auto test, auto code quality, sast, etc. Perhaps running only those stages would be the right approach cc @DylanGriffith

Actually even with no cluster there are many stages that could be advantageous, such as auto test, auto code quality, sast, etc. Perhaps running only those stages would be the right approach

@danielgruesso yes I agree. In fact right now we do already skip the auto deploy stages when there is no cluster active for the project. That being said we could improve things a little by skipping the build stage if there is no Dockerfile but this is tricky at the moment and we have an existing issue at https://gitlab.com/gitlab-org/gitlab-ce/issues/49223

@danielgruesso this issue does seem to bring up another important problem though where people cannot merge with external CI (eg. Jenkins) and we will need to figure out how to resolve this as this is a really bad UX.

@DylanGriffith in general we shouldn't enable auto devops on projects that don't have CI enabled. But the larger opportunity I see here is allowing users with no cluster set up to take advantage of all the other stages and don't present failures that don't apply.

added to epic &250

Thanks for the reply @danielgruesso ! The problem i'd like to outline is that auto test, auto code, etc. can not run when there is no environment to run on. When you have 0 gitlab runner configured / active, the pipeline will fail because no runner is available.

Oh, i just noticed the issue you related, makes my comment unnecessary :D

mentioned in issue #11765 (closed)

added devopsconfigure [DEPRECATED] + 1 deleted label and removed devopsverify label

added [deprecated] Accepting merge requests label

removed [deprecated] Accepting merge requests label

added Enterprise Edition label

added groupconfigure [DEPRECATED] label

added sectionops label

Closing due to age of the issue and lack of further demand. Please reopen if needed.

closed

added groupenvironments label and removed groupconfigure [DEPRECATED] label