bake version info into binary for logging

[BenTheElder]

we have version info in the tags we push, but we should probably also bake it into the binary for logging. we can use a golang x-def and update the build commands.

ideally this should be fully sortable git info, see kubernetes-sigs/kind#2618, and also a starting non-fully-sortable version of embedding this info in a similar makefile in that repo as a starting point.

[ameukam]

/sig k8s-infra

Ref: kubernetes/k8s.io#3411

Possible to use https://tip.golang.org/doc/go1.18#debug/buildinfo ?

[BenTheElder]

it might be if we upgrade to 1.18!

/help

[k8s-ci-robot]

@BenTheElder:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

it might be if we upgrade to 1.18!

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[BenTheElder]

Possible to use https://tip.golang.org/doc/go1.18#debug/buildinfo ?

TLDR: no.

1. That package is used to read build info from entire (on disk or embedded in memory) binaries. The main debug package can be used to get info though.
2. ... but buildinfo for untagged versions / current development has the main module version just as (devel)
3. .... and even the buildinfo build settings metdata just has vcs ("git"), commit hash, and timestamp, we want something closer to git describe which is sortable (includes #commits since tag) for merged commits

As long as we can figure out how to get ko to pass these as well, we can just set xdef with the metadata ourselves in the build target(s), kind has an example that is close to what we want.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ameukam]

/remove-lifecycle stale

[BenTheElder]

TODO: remove lifecycle bot from this repo.

[BenTheElder]

I think this is deep on the backlog, it sounds nice to have, but we also have other ways to see what cloudrun is up to and we're only using tagged images in production.

Ordinarily for help wanted issues the author would probably help guide contributors, but I am going on vacation for a few weeks and will be relatively unavailable until sometime after July 25th.

@ameukam and @dims are repo approvers / admins and should be able to help in the meantime.

See also https://kubernetes.slack.com/archives/CCK68P2Q2/p1656629484801139?thread_ts=1656626472.238269&cid=CCK68P2Q2 in Kubernetes slack.

[riaankleinhans]

/retitle bake version info into binary for logging

[BenTheElder]

we're not changing the version often and we know what image is deployed in cloud run config (and we're using digests so it's an exact image), so this remains low priority.

[BenTheElder]

Cloud run gives us detailed info about revisions to services, I don't think this will actually help and it has the downside of making the build reproducibility dependent on git info. We can already trace back deploys to specific images and the associated commit