Follow-up from "GitLab CI cleanup"

The following discussion from !1329 (merged) should be addressed:

• @michal started a discussion: (+3 comments)

  Without rebasing, I renamed CI jobs as agreed upon earlier; the diff from the previous version of the branch looks fairly legible to me.

  @ondrej, I think this achieves what you asked for, but please take a look at https://gitlab.isc.org/isc-projects/bind9/pipelines/8771 to confirm that.

  While examining job output for the pipeline linked to above, I noticed an issue which was not introduced by this branch: the job testing make install does not just install stuff, but rather does an almost complete rebuild first. This is caused by how artifacts are passed between jobs: when a runner for the "install" job clones the tested revision and subsequently extracts the artifacts that the "build" job produced, modification times for the versioned source files inside the working copy turn out to be more recent than the timestamps of the object files extracted from the artifacts archive. This causes make to believe that it needs to rebuild stuff.

  I see no elegant way to solve this, because:

  • Updating the timestamps for all files and directories in the working copy for the "install job" to the same value (e.g. using find . | xargs touch) does us no good as that would also cause rebuilds (since dependencies are built in a specific order and this order has to be reflected in timestamps in order for a rebuild to be prevented).

  • We could store the modification time for each file created by the "build" job in a separate file and then, in the "install" job, update the timestamp for each file extracted from the artifacts archive to the stored timestamp + some constant delta, but that would trigger a lot of "Warning: File 'Makefile' has modification time XXXX s in the future" messages in the job output (though I believe it would achieve the desired effect).

  • The above warnings cannot be fully prevented from appearing even if we calculated the timestamp delta dynamically in the "install" job (e.g. "move timestamps for all extracted files by the difference between current time and the lowest timestamp found amongst all the extracted files") as the "install" job runs quicker than the "build" job.

  I believe our options here are:

  • Ignore this and just let the "install" job rebuild stuff.

  • Choose the second approach listed above, ignoring the warnings about timestamps set in the future.

  • Run make install in the "build" job (theoretically, this might delay the start of the entire "Test" phase of the pipeline, but I do not think it would be noticeable, given the statistical differences in run time between various jobs in the "Build" phase).

  @ondrej, thoughts, any other ideas for addressing this?