Inconsistent behaviour with retries for jobs with an empty environment name

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

User experience is not ideal for cases when environment name is accidentally configured as an empty value. There are two issues with it:

  1. The error message received when users run such jobs is not pointing out the fact that the name of the environment is empty, it prints a generic error: This job could not be executed because it would create an environment with an invalid parameter.. We should point out that the environment name is empty instead.
  2. Upon job re-try, the job doesn't give the same error, but instead proceeds with the following message:

image

This behavior is inconsistent, the job should fail with the same error upon retry.

Scope This issue is about the re-try behaviour. The unhelpful message is being addresses in Improve user experience when environment name p... (#455090)

Steps to reproduce

  1. given some project A
  2. define a pipeline with a job that targets environment named dynamically to variable $ACTIVE_NONPROD_ENVIRONMENT (this environment is not set)
  3. run pipeline
job:
    environment:
        name: $ACTIVE_NONPROD_ENVIRONMENT
  1. pipeline fails because minimal job fails: "This job could not be executed because it would create an environment with an invalid parameter. How do I fix it?"
  2. attempt to re-run
  3. succeeds even though environment does not exist

Example Project

https://gitlab.com/gl-demo-ultimate-khrechyshkina/tickets/zd516022

What is the current bug behavior?

Unclear message doesn't point out the fact that the env name is empty. The job can be executed if retried even though the environment name is still empty.

What is the expected correct behavior?

The job should show consistent error message upon retries. The error should point to the fact that environment name is empty, instead of showing the generic message it does now.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info 
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Edited by 🤖 GitLab Bot 🤖