Stop environment shows a note about not having an effect on any existing deployment

Summary

When I click "Stop" on an environment, I get:

Note that this action will stop the environment, but it will not have an effect on any existing deployment due to no “stop environment action” being defined in the .gitlab-ci.yml file.

with two buttons, « Cancel » and « Stop environment ».

When I click « Stop environment » it does start the stop job which correctly cleans the deployment.

Steps to reproduce

  • Create a new project
  • Clone it to add a .gitlab-ci.yml as:
---

image: debian:stable-slim

variables:
  LC_ALL: "C.UTF-8"
  LANG: "C.UTF-8"

default:
  tags: [docker]

stages:
  - test
  - staging

test:
  stage: test
  script:
    - echo running tests

teardown_staging:
  stage: staging
  only:
    - '/^staging/'
  environment:
    name: staging/$CI_COMMIT_REF_SLUG
    action: stop
  script:
    - echo tearing down staging for $CI_COMMIT_REF_SLUG
  when: manual


deploy to staging:
  stage: staging
  only:
    - '/^staging/'
  environment:
    name: staging/$CI_COMMIT_REF_SLUG
    url: https://example.com/$CI_COMMIT_REF_SLUG
    on_stop: teardown_staging
  script:
    - echo setting up staging for $CI_COMMIT_REF_SLUG
  • git add .gitlab-ci.yml
  • git commit -m "Initial commit"
  • git push
  • git switch -c "staging-test-1"
  • git push # This triggers a 1st deployment
  • Now I see 1 available environment "staging/staging-test-1"
  • On the environment page I click "Stop" I get the message "Note that this action will stop the environment, but it will not have an effect on any existing deployment due to no “stop environment action” being defined in the .gitlab-ci.yml file".
  • Click stop environment anyway
  • Check the pipeline page, see the stop job is running!
  • Consult the job and see the script has run properly: "tearing down staging for staging-test-1"

What is the current bug behavior?

As it works I just don't expect to see the notice telling me it won't work.

What is the expected correct behavior?

  • If there is no on_stop: action, show This action will stop the environment. It will not affect existing deployments because no on_stop action is defined in the .gitlab-ci.yml file. Are you sure you want to stop this environment?

  • If there is an on_stop: action, show Are you sure you want to stop this environment?

Possible fix

#358939 (comment 1308118910)

@shinya.maeda looks like this was missed as part of the redesign work. by the time everything has reached this component it is in camelCase instead of snake_case 🤦

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

# gitlab-rake gitlab:env:info

System information
System:		Debian 10
Current User:	git
Using RVM:	no
Ruby Version:	2.7.5p203
Gem Version:	3.1.4
Bundler Version:2.2.33
Rake Version:	13.0.6
Redis Version:	6.2.6
Sidekiq Version:6.4.0
Go Version:	unknown

GitLab information
Version:	14.9.2
Revision:	56bec66a79f
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	12.7
URL:		redacted for privacy
HTTP Clone URL:	redacted for privacy
SSH Clone URL:	redacted for privacy
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: 

GitLab Shell
Version:	13.24.0
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Results of GitLab application Check

Expand for output related to the GitLab application check 
gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...

Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 13.24.0 ? ... OK (13.24.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Checking Reply by email ...


IMAP server credentials are correct? ... Checking no-reply@redacted for privacy
no
Try fixing it:
An error occurred: Net::IMAP::NoResponseError:  Invalid credentials (Failure)
Check that the information in config/gitlab.yml is correct
For more information see:
doc/administration/reply_by_email.md
Please fix the error above and rerun the checks.
Mailroom enabled? ... skipped
MailRoom running? ... skipped


Checking Reply by email ... Finished


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


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
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ...
12/1 ... yes
21/3 ... yes
19/4 ... yes
17/5 ... yes
20/6 ... yes
20/7 ... yes
20/8 ... yes
20/9 ... yes
22/10 ... yes
13/11 ... yes
21/12 ... yes
20/13 ... yes
20/14 ... yes
13/15 ... yes
13/16 ... yes
22/17 ... yes
17/18 ... yes
19/19 ... yes
19/20 ... yes
22/21 ... yes
22/22 ... yes
22/23 ... yes
19/24 ... yes
21/26 ... yes
13/27 ... yes
21/28 ... yes
21/30 ... yes
21/31 ... yes
21/32 ... yes
13/33 ... yes
19/34 ... yes
22/35 ... yes
21/36 ... yes
19/37 ... yes
19/38 ... yes
19/39 ... yes
19/40 ... yes
22/41 ... yes
19/42 ... yes
12/43 ... yes
19/44 ... yes
19/45 ... yes
12/46 ... yes
12/47 ... yes
19/48 ... yes
11/49 ... yes
19/50 ... yes
11/51 ... yes
12/52 ... yes
28/53 ... yes
22/54 ... yes
12/55 ... yes
12/56 ... yes
19/57 ... yes
12/58 ... yes
30/59 ... yes
30/60 ... yes
22/61 ... yes
22/62 ... yes
22/63 ... yes
12/64 ... yes
11/65 ... yes
29/67 ... yes
12/68 ... yes
29/69 ... yes
12/70 ... yes
29/71 ... yes
19/72 ... yes
12/73 ... yes
12/74 ... yes
19/75 ... yes
19/76 ... yes
12/77 ... yes
11/78 ... yes
29/79 ... yes
12/80 ... yes
19/81 ... yes
19/83 ... yes
13/85 ... yes
13/86 ... yes
19/87 ... yes
19/88 ... yes
13/89 ... yes
12/90 ... yes
29/92 ... yes
33/93 ... yes
33/94 ... yes
33/95 ... yes
8/96 ... yes
13/97 ... yes
19/98 ... yes
19/99 ... yes
25/100 ... yes
19/101 ... yes
12/102 ... yes
22/103 ... yes
21/104 ... yes
12/105 ... yes
13/106 ... yes
22/107 ... yes
19/109 ... yes
11/110 ... yes
8/111 ... yes
19/112 ... yes
19/113 ... yes
37/114 ... yes
36/115 ... yes
19/116 ... yes
19/117 ... yes
19/118 ... yes
21/119 ... yes
21/120 ... yes
2/121 ... yes
12/122 ... yes
12/123 ... yes
8/124 ... yes
22/125 ... yes
53/126 ... yes
19/127 ... yes
12/128 ... yes
22/129 ... yes
19/130 ... yes
21/131 ... yes
12/132 ... yes
22/133 ... yes
12/134 ... yes
6/135 ... yes
19/136 ... yes
19/137 ... yes
12/138 ... yes
6/139 ... yes
61/140 ... yes
61/141 ... yes
61/142 ... yes
8/143 ... yes
Redis version >= 5.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.5)
Git user has default SSH configuration? ... yes
Active users: ... 12
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished
Edited by Shinya Maeda