Set created-at timestamps to time of last change about images HOT 6 OPEN

docker/cli#3778 addresses this issue in the Docker CLI, so that images reporting as built before 2000 aren't shown as X years ago, but instead N/A.

When that change is released (assuming December), we should stop bumping the created-at date every day, basically resurrecting chainguard-images/actions#30.

from images.

Just reading https://www.chainguard.dev/unchained/conquer-your-build-horizon-with-chainguard-enforce-in-2023 I suggest we just use last commit date for our CG images. Could we just do this now?

from images.

Just reading https://www.chainguard.dev/unchained/conquer-your-build-horizon-with-chainguard-enforce-in-2023 I suggest we just use last commit date for our CG images. Could we just do this now?

I thought about this a bit more, and I don't think we can. Or we can, but it might become misleading.

There are roughly two sources of "changes" to an image we build:

1. the apko.yaml file in the source repo
2. the packages in the apk repo

Setting SOURCE_DATE_EPOCH=$(git show -s --format=%at HEAD) would make the image's created-at date based only on source updates, basically (1).

The problem is that even if you don't change your apko.yaml in GitHub, requesting a package like packages: ['busybox'] in the config might install busybox-1.34.1-r0 today, but could install busybox-1.35.4-r5 tomorrow. The config contents hasn't changed, but the image contents might have. We'd be ignoring (2). An image could be "created at" a time before one of its packages even existed.

The root of this issue is that, if the source contents haven't changed, and the packages haven't changed, then the timestamp shouldn't change either. This is what we're getting wrong today: identical config+packages still bumps the created-at time, because we always set it to "now".

We could also tie (1) to (2), and always explicitly request packages by exact version (packages: ['busybox-1.34.1.-r0']), but that would get really tedious and brittle and noisy. Nobody wants to live like this.

So ideally we should come up with some way to grab the installed packages' created-at times, and set the image's created-at time to max(commit-time, package-update-times...). I'm not sure the best way to do that today.

edit to add: I think this logic seems sufficiently complex and in need of testing that we should write it in Go instead of Bash. This might be better behavior to bake into apko (possibly as the default?) than to hack together just for our images.

from images.

There's a third source of change: the apko version used to build the image. Luckily we have this in apko's version info.

Also worth considering, now that we build images from the monorepo we need to ignore changes to other files. For (1), instead of "date of last commit" it should be "date of last commit affecting the build config"

Definitely sounds like something apko should be responsible for.

from images.

keep in mind that SOURCE_DATE_EPOCH needs to be respected regardless, because SBOM data gets embedded in apks

from images.

The problem is that even if you don't change your apko.yaml in GitHub, requesting a package like packages: ['busybox'] in the config might install busybox-1.34.1-r0 today, but could install busybox-1.35.4-r5 tomorrow.

Would this (chainguard-dev/apko#185) solve that problem?

from images.