Fails on GitLab when triggering a new pipeline on a branch without new commits

[christophebedard]

Job after a merge to master: https://gitlab.com/micro-ROS/ros_tracing/tracetools_analysis/-/jobs/612272575

Detected: GitLab
on default branch 'master': will check new commits
Checking commits: 38da641ae4ed7472a814e10ac3513b0c3e5e763a..10310dbd8c3ac5e8e505a9292becaede0bfeff1a

Nightly job that was triggered a bit later (no new changes): https://gitlab.com/micro-ROS/ros_tracing/tracetools_analysis/-/jobs/612419164

Detected: GitLab
on default branch 'master': will check new commits
Checking commits: 0000000000000000000000000000000000000000..10310dbd8c3ac5e8e505a9292becaede0bfeff1a
error: fatal: Invalid revision range 0000000000000000000000000000000000000000..10310dbd8c3ac5e8e505a9292becaede0bfeff1a

So it would seem that this line & the CI_COMMIT_BEFORE_SHA env var give an invalid SHA:

dco-check/dco_check/dco_check.py

Line 619 in 444eac1

commit_hash_base = get_env_var('CI_COMMIT_BEFORE_SHA')

[christophebedard]

Weird behaviour for CI_COMMIT_BEFORE_SHA, as reported here:

• https://gitlab.com/gitlab-org/gitlab/-/issues/7898
• https://gitlab.com/gitlab-org/gitlab/-/issues/12850

[christophebedard]

Findings:

• CI_COMMIT_BEFORE_SHA is all zeros when pushing a new branch: https://gitlab.com/micro-ROS/ros_tracing/tracetools_analysis/-/jobs/613013361
• works when pushing to an existing branch: https://gitlab.com/christophebedard/tracetools_analysis/-/jobs/613067025
• works if I retry that job: https://gitlab.com/christophebedard/tracetools_analysis/-/jobs/613071839
• all zeros if triggered by a schedule: https://gitlab.com/christophebedard/tracetools_analysis/-/jobs/613076623

So the problem seems to be schedules. It would make sense to not run dco-check or have it do nothing if it's a scheduled pipeline. A simpler solution could be to set commit_hash_base to commit_hash_head if commit_hash_base is all zeros. This way it won't check anything and is rather simple.

However, if the schedule is not on the default branch (which definitely happens), then it will try to check commits off of the default branch (given the current logic in GitlabRetriever.get_commit_range()), which still doesn't really make sense. Therefore, we could simply detect the schedule (CI_PIPELINE_SOURCE == schedule) and not do anything/set base to head and mention it in a verbose_print().