Closed christophebedard closed 4 years ago
Weird behaviour for CI_COMMIT_BEFORE_SHA
, as reported here:
Findings:
CI_COMMIT_BEFORE_SHA
is all zeros when pushing a new branch: https://gitlab.com/micro-ROS/ros_tracing/tracetools_analysis/-/jobs/613013361So 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()
.
Job after a merge to
master
: https://gitlab.com/micro-ROS/ros_tracing/tracetools_analysis/-/jobs/612272575Nightly job that was triggered a bit later (no new changes): https://gitlab.com/micro-ROS/ros_tracing/tracetools_analysis/-/jobs/612419164
So it would seem that this line & the
CI_COMMIT_BEFORE_SHA
env var give an invalid SHA: https://github.com/christophebedard/dco-check/blob/444eac10b8a8c357d1b52c662c6e6f1c13a6ee63/dco_check/dco_check.py#L619