bake: add unixtimestampparse and formattimestamp functions

[crazy-max]

fixes #3197

Adds unixtimestampparse similar to terraform unix_timestamp_parse function. Also adds formattimestamp as a superset of formatdate so timestamps can be formatted from either an RFC3339 string or a unix timestamp integer. Keeps formatdate for compatibility and marks it as deprecated for new usage.

cc @sdavids

[sdavids]

One uses SOURCE_DATE_EPOCH as follows:

$ SOURCE_DATE_EPOCH=0 docker buildx bake
$ SOURCE_DATE_EPOCH=42 docker buildx bake

Does this PR support this use case?

SOURCE_DATE_EPOCH is used to pass a fixed timestamp from the outside into the build.

—

Having this rfc3339parse function is appreciated as well …

[crazy-max]

One uses SOURCE_DATE_EPOCH as follows:

$ SOURCE_DATE_EPOCH=0 docker buildx bake
$ SOURCE_DATE_EPOCH=42 docker buildx bake

Does this PR support this use case?

SOURCE_DATE_EPOCH is used to pass a fixed timestamp from the outside into the build.

This is already supported as a standardized environment variable

Edit: We only have docs for it in https://docs.docker.com/build/ci/github-actions/reproducible-builds/ but I think we should also have some for build and bake. Maybe in https://docs.docker.com/build/building/variables/#build-tool-configuration-variables. cc @ArthurFlag

[sdavids]

Maybe I was not clear enough in #3197:

$ SOURCE_DATE_EPOCH=0 docker buildx bake

labels = {
    "org.opencontainers.image.created" = "how do I get SOURCE_DATE_EPOCH as an RFC3339-formatted string here"
}

The label should look like "org.opencontainers.image.created"="1970-01-01T00:00:00.000Z" and not "org.opencontainers.image.created"="0"

[crazy-max]

Maybe I was not clear enough in #3197:

$ SOURCE_DATE_EPOCH=0 docker buildx bake

labels = {
    "org.opencontainers.image.created" = "how do I get SOURCE_DATE_EPOCH as an RFC3339-formatted string here"
}

The label should look like "org.opencontainers.image.created"="1970-01-01T00:00:00.000Z" and not "org.opencontainers.image.created"="0"

Pushed extra commit to add unixtimestampparse similar to terraform unix_timestamp_parse function and update examples in docs: https://github.com/crazy-max/buildx/blob/bake-rdc339parse/docs/bake-stdlib.md#-rfc3339parse

[tonistiigi]

I don't think this is a convention that we would want to promote. Users should set SOURCE_DATE_EPOCH in the env as UNIX timestamp, not BUILD_TIME as string, so that bake uses the same convention as other apps.

[crazy-max]

Indeed, this was just for example purpose, renamed SOURCE_DATE_EPOCH to BUILD_TIMESTAMP.

[tonistiigi]

how about

variable "SOURCE_DATE_EPOCH" {
  type    = number
  default = formattimestamp("X", "2015-10-21T00:00:00Z")
}

target "default" {
  args = {
    SOURCE_DATE_EPOCH = SOURCE_DATE_EPOCH
    BUILD_TIME = formattimestamp("YYYY-MM-DD'T'00:00:00Z", SOURCE_DATE_EPOCH)
  }
}

I'm also ok for special formatting for rfc3399 for less verbosity.

[crazy-max]

I looked at forking FormatDateFunc func as they are not willing to accept timestamp format: zclconf/go-cty#130 (comment) but there's quite a lot to fork and it might be better to be aligned so users are not confused. So that's why I opted for the terraform unix_timestamp_parse function func instead.

[crazy-max]

Updated with new formattimestamp func

[tonistiigi]

(looks like github skipped my main review message, reposing in case it doesn't appear)

Still somewhat confused about this.

• what is the use case for rfc4449parse? We would want to the SOURCE_DATE_EPOCH to be the source of truth that is picked up from env as that is the convention and that is already unix.
• Is returning a big struct like these new functions do some kind of convention. Can't find anything similar from current stdlib. The current convention seems to be formatdate. If we don't want to modify formatdate to have the capability to take date as UNIX timestamp (and maybe to return it) then would it make sense to add a new function, eg. formattimestamp that is the superset of the existing function (and then hide/deprecate the previous formatdate).

[crazy-max]

(looks like github skipped my main review message, reposing in case it doesn't appear)

Still somewhat confused about this.

• what is the use case for rfc4449parse? We would want to the SOURCE_DATE_EPOCH to be the source of truth that is picked up from env as that is the convention and that is already unix.

Removed rfc4449parse func and just keep unixtimestampparse one to be consistent with Terraform unix_timestamp_parse function func.

• Is returning a big struct like these new functions do some kind of convention. Can't find anything similar from current stdlib. The current convention seems to be formatdate. If we don't want to modify formatdate to have the capability to take date as UNIX timestamp (and maybe to return it) then would it make sense to add a new function, eg. formattimestamp that is the superset of the existing function (and then hide/deprecate the previous formatdate).

Yes I think as follow-up we could have a formattimestamp func.