feat: use HistoryTimestamp, if set, for oci-archive entries

[aeijdenberg]

What type of PR is this?

/kind feature

What this PR does / why we need it:

This PR passes the existing HistoryTimetamp option, if set, to the CopyOptions passed to the image/v5 library, which in turn uses this for timestamps for some destinations, specifically oci-archive.

How to verify it

Before this change, this command will produce different output on each run (provided each run is at least 1 second apart):

$ ./bin/buildah build -f <(echo 'FROM scratch') --tag=oci-archive:oci.tar --timestamp 0 &>/dev/null && sha256sum oci.tar
182557b969fb24723b29e18770a2add930115492b4b267bb0847cecc14b47647  oci.tar
$ ./bin/buildah build -f <(echo 'FROM scratch') --tag=oci-archive:oci.tar --timestamp 0 &>/dev/null && sha256sum oci.tar
cb7ffa809d00485700d207ea291c8be8939b5596c9d04deeeacf7e26beb0e7aa  oci.tar

After this change, the same output is produced each time:

$ ./bin/buildah build -f <(echo 'FROM scratch') --tag=oci-archive:oci.tar --timestamp 0 &>/dev/null && sha256sum oci.tar
b5706eba1022041e2eeceada4f0da68ccd002c768ddb9e28e4dd5ca422f73cd1  oci.tar
$ ./bin/buildah build -f <(echo 'FROM scratch') --tag=oci-archive:oci.tar --timestamp 0 &>/dev/null && sha256sum oci.tar
b5706eba1022041e2eeceada4f0da68ccd002c768ddb9e28e4dd5ca422f73cd1  oci.tar

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

I'm guessing we would normally wait for a new version of github.com/containers/image/v5 to be released before bumping?

Does this PR introduce a user-facing change?

The --timestamp option, if set, is now passed through to a destination of --tag=oci-archive: and is applied to the timestamp of entries in the tar archive.

[aeijdenberg]

This is the 3rd part of 3 PRs - it relies on the following already merged PRs in dependent libraries, which is why it bumps the versions of each:
containers/storage#2259
containers/image#2730

[nalind]

I'm guessing we would normally wait for a new version of github.com/containers/image/v5 to be released before bumping?

Yeah, normally a bot opens those when it spots a new upstream release, and I try to discourage updating to non-tagged versions of dependencies that tag their releases. Are you sure a version bump was necessary here? That new DestinationTimestamp option appears to be in containers/image v5.34.1, which was the version that was being pulled in before the current version of this PR attempted to bump it.

Undoing the dependency bumps will cut the number of files this PR touches down significantly, making this much easier to review. I'm pretty sure the validation hooks will complain about there not being a new test to ensure that the new change produces the desired effect, but you've got most of what that test would need to do already written in the description.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[aeijdenberg]

Yeah, normally a bot opens those when it spots a new upstream release, and I try to discourage updating to non-tagged versions of dependencies that tag their releases. Are you sure a version bump was necessary here? That new DestinationTimestamp option appears to be in containers/image v5.34.1, which was the version that was being pulled in before the current version of this PR attempted to bump it.

I didn't see it in v5.34.1 (at least it didn't build for me). While that release was cut chronologically after DestinationTimestamp was added, it looks like they did so from a release branch, so we might need to wait for their next bump to get this change.

Undoing the dependency bumps will cut the number of files this PR touches down significantly, making this much easier to review. I'm pretty sure the validation hooks will complain about there not being a new test to ensure that the new change produces the desired effect, but you've got most of what that test would need to do already written in the description.

Yep, it's a 3 line change without the dependency bump. I've added a test (first time seeing bats so let me know if I've done it badly), and separated the commits.

First time contributing to this project, so figured I'd get the PR open and in shape while we wait for the upstream library's next release. Appreciate your time in looking at it.

[nalind]

I didn't see it in v5.34.1 (at least it didn't build for me). While that release was cut chronologically after DestinationTimestamp was added, it looks like they did so from a release branch, so we might need to wait for their next bump to get this change.

Ugh, you're right, I must've been misreading the git history.

Yep, it's a 3 line change without the dependency bump. I've added a test (first time seeing bats so let me know if I've done it badly), and separated the commits.

Nope, the test looks good. Thanks!

[aeijdenberg]

Will wait to rebase until v5.35 (presumably) is released for https://github.com/containers/image

[nalind]

It looks like #6073 bumped us to using a commit on main anyway - any chance you'd like to rebase without the bits that touch go.mod/go.sum/vendor?

[aeijdenberg]

It looks like #6073 bumped us to using a commit on main anyway - any chance you'd like to rebase without the bits that touch go.mod/go.sum/vendor?

Done, thanks.

[siteshwar]

There is a warning reported by OpenScanHub. Is it a real bug?

[aeijdenberg]

Thanks, you're quite right. I'd tested the 2nd part (which was the main test) but didn't notice this failed to fail. I've fixed as per one of the suggestions in https://bats-core.readthedocs.io/en/stable/gotchas.html#my-negated-statement-e-g-true-does-not-fail-the-test-even-when-it-should

[siteshwar]

No problem. In the future please check the results from osh-diff-scan job submitted through Packit.

[nalind]

Thanks!
/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aeijdenberg, nalind

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [nalind]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment