Improve flash message and write error details to logs when running pipeline schedules manually

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

Summary

When a pipeline schedule is run manually using the play button, GitLab shows a message: Successfully scheduled a pipeline to run. Go to the Pipelines page for details. if it is able to schedule a sidekiq job to create a pipeline immediately. But, it doesn't check if a pipeline was actually created. It leads to confusions when a sidekiq job was created to schedule a pipeline, but the actual pipeline was not created for some reason.

It is also worth noting that, no error message related to the failure of creation of pipeline is being written to any of the log files.

It'd be awesome if the above flash message is reworded, or if we can show the correct pipeline creation status from the actual worker method. We'd also need to log any error messages.

Steps to reproduce

  • Create a project with a simple CI file.
  • Create a branch: schedule-branch to run the schedule.
  • Create a schedule for the branch schedule-branch.
  • Delete the branch schedule-branch.
  • Run the pipeline manually by clicking on the play button.

It will now show the flash message: Successfully scheduled a pipeline to run. Go to the Pipelines page for details., but in reality, a pipeline will not be created due to the non-existence of target branch.

There are many reasons by which a schedule can fail. Above(non-existing branch) is just an example.

Example Project

Schedule page on the example project: https://gitlab.com/psureshbabu/schedule/-/pipeline_schedules Run the play button for schedule: Schedule on schedule-branch. It will show a success message but a pipeline wont be created.

What is the current bug behavior?

  • GitLab shows a success message even if a pipeline is not created. Though the current message says Successfully scheduled a pipeline to run, it can be misinterpreted easily by the users that a pipeline has been created.

What is the expected correct behavior?

  • GitLab should show the actual pipeline creation status with error messages if any.
  • If the above is not possible, a clear message should be shown regarding the job schedule.
  • Error messages from run_pipeline_schedule method should be written to the rails logs.

Relevant logs and/or screenshots

If I run run_pipeline_schedule directly on the rails console, it prints a message. But it doesn't write anything to logs:

rb(main):001:0> schedule = Ci::PipelineSchedule.find_by(id: 5)
=> #<Ci::PipelineSchedule id: 5, description: [FILTERED], ref: "anaconda", cron: "0 18 * * *", cron_timezone: "UTC", next_run_at: "2021-02-03 18:19:00", project_id: 44, owner_id: 1, active: true, created_at: "2021-01-31 05:39:29", up...
irb(main):002:0> user = User.find_by_id(1)
=> #<User id:1 @root>
irb(main):003:0> pi = Ci::CreatePipelineService.new(schedule.project, user, ref: schedule.ref).execute!(:schedule, ignore_skip_ci: true, save_on_errors: false, schedule: schedule)
Traceback (most recent call last):
        4: from (irb):3
        3: from app/services/ci/create_pipeline_service.rb:101:in `execute!'
        2: from app/services/ci/create_pipeline_service.rb:101:in `tap'
        1: from app/services/ci/create_pipeline_service.rb:103:in `block in execute!'
Ci::CreatePipelineService::CreateError (Reference not found)

But if I run RunPipelineScheduleWorker.perform_async in rails console, it shows the below message on sidekiq log:

{"severity":"WARN","time":"2021-01-31T06:05:28.072Z","class":"Git::BranchHooksService","correlation_id":"01EXBGQM0FCQMS82XQBJ9PTSME","project_id":44,"project_path":"root/schedule","message":"Error creating pipeline","errors":"Reference not found","pipeline_params":{"before":"375eea666c96387c87c83323c46316451c6898a1","after":"0000000000000000000000000000000000000000","ref":"refs/heads/anaconda","variables_attributes":[],"checkout_sha":null},"retry":0}

In any case, UI doesn't show any error messages:

image

Output of checks

This bug happens on GitLab.com as well.

Results of GitLab environment info

Expand for output related to GitLab environment info 
root@psureshbabu-gitlab:~# sudo gitlab-rake gitlab:env:info

System information
System:		Ubuntu 18.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.7.2p137
Gem Version:	3.1.4
Bundler Version:2.1.4
Rake Version:	13.0.3
Redis Version:	5.0.9
Git Version:	2.29.0
Sidekiq Version:5.2.9
Go Version:	unknown

GitLab information
Version:	13.8.1-ee
Revision:	e10a21e66ce
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	12.4
URL:		https://psureshbabu-gitlab.sr.gitlab.support
HTTP Clone URL:	https://psureshbabu-gitlab.sr.gitlab.support/some-group/some-project.git
SSH Clone URL:	git@psureshbabu-gitlab.sr.gitlab.support:some-group/some-project.git
Elasticsearch:	yes
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:

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

Results of GitLab application Check

Expand for output related to the GitLab application check 
root@psureshbabu-gitlab:~# sudo gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 13.15.0 ? ... OK (13.15.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 ... 1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


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


Checking LDAP ... Finished


Checking GitLab App ...


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: ...
2/1 ... yes
1/2 ... yes
1/3 ... yes
1/4 ... yes
5/7 ... yes
1/9 ... yes
4/10 ... yes
6/11 ... yes
6/12 ... yes
1/13 ... yes
1/14 ... yes
1/16 ... yes
13/17 ... yes
13/18 ... yes
1/19 ... yes
6/20 ... yes
1/21 ... yes
1/22 ... yes
1/23 ... yes
1/24 ... yes
1/25 ... yes
1/26 ... yes
1/27 ... yes
1/28 ... yes
1/29 ... yes
1/30 ... yes
1/31 ... yes
1/32 ... yes
1/33 ... yes
14/34 ... yes
1/35 ... yes
1/36 ... yes
1/37 ... yes
1/38 ... yes
1/39 ... yes
1/40 ... yes
1/41 ... yes
1/42 ... yes
1/43 ... yes
1/44 ... yes
1/45 ... yes
1/46 ... yes
1/47 ... yes
Redis version >= 4.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.2)
Git version >= 2.29.0 ? ... yes (2.29.0)
Git user has default SSH configuration? ... yes
Active users: ... 3
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x (6.4 - 6.x deprecated to be removed in 13.8)? ... Exception: Connection refused - Connection refused - connect(2) for "127.0.0.1" port 9200 (localhost:9200)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

Edited by 🤖 GitLab Bot 🤖