Closed mattmoor closed 1 year ago
cc @kaniini @deitch @imjasonh
I am guessing that for this we want to set this here: https://github.com/wolfi-dev/os/blob/f70db1ba4de2b81e4307cdae5469e50d807690ce/Makefile#L44
Based on the mtime of $(pkgname).yaml
when ${SOURCE_DATE_EPOCH}
is not set?
We could also just have melange
do this directly (os.Stat
the file and set things accordingly), WDYT @kaniini?
We cannot do this inside of melange
itself because git
doesn't bother to set timestamps in a fresh clone.
I just cloned a fresh copy of this repo, and I see:
-rw-r--r-- 1 mattmoor wheel 406 May 14 20:55 ./images/apko/configs/latest.apko.yaml
However, I think what we actually want here is to set SOURCE_DATE_EPOCH
based on the timestamp of the actual melange
file with something like this:
git log -1 --pretty=%ct --follow images/apko/configs/latest.apko.yaml
According to time.Unix(...).Format(time.RFC3339)
for this file is 2023-04-27T20:01:35Z
, which checks out:
We reverted this due to it breaking arm builds :-/
This is related to this issue.
I was talking to @kaniini about how we get better
SOURCE_DATE_EPOCH
for our APKs (to feed into a smarter default for our images), and thetl;dr
is:Initially, I was overcomplicating this, thinking that it should be some combination of the proper
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
and the melange config'smtime
, but unlikeapko
(which floats forward APKs),melange
essentially always pins to one of a release tag or commit SHA. So in essence, the melange config'smtime
is always after the commit timestamp because it references it!I believe that this should result in us getting timestamps on our APKs, which change exactly when they should.