Use commit-timestamp in tasks in pursuit of reproducible builds

[ralphbean]

There are lots of challenges to producing bit-wise reproducible builds. One of them is to get all tools all the way through the build chain to use the same time. See https://reproducible-builds.org/docs/ and in particular https://reproducible-builds.org/docs/source-date-epoch/

• We should expose commit-timestamp as SOURCE_BUILD_EPOCH in all of our tasks. Not all tools respect that, but it is the standard environment variable that they should respect.
• Notably, buildah doesn't respect it, but it does accept a --timestamp argument that will help produce the same bits, assuming that nothing inside the containerfile being built is not sensitive to the time.
• We should also provide a --build-arg SOURCE_BUILD_EPOCH=$SOURCE_BUILD_EPOCH to each buildah build, so that if a containerfile accepts that as an ARG, it can take advantage of that.

Doing these things won't give us all 100% bit-wise reproducible builds, but it will close some gaps in that direction.

[pierDipi]

One issue we noticed that is related to not having reproducible builds is:

We have an operator repository that is aggregating other components images using the custom latest tag which eventually turns into a resolved SHA.

when a pipeline runs on push for any "other components", a task after pushing or apply-tags could fail (for whatever reason), in that case, if we re-run the pipeline, the image revision (and therefore tag) is the same, but the SHA is different which ends up invalidating the "previous SHAs" in the operator repository.

So far, I see only a few solutions:

• run apply-tags task only if all other tasks succeeded
• append a timestamp to the "default revision tag" so that no SHA is "invalidated" (unclear if this is possible, given the list here: https://pipelinesascode.com/docs/guide/authoringprs/#dynamic-variables)