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

[christophebedard]

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

[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().