-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config: Insert git sha when using configupdater #20527
Conversation
6a328db
to
714e9a2
Compare
This change makes the configupdater always add a key named VERSION to the configmap which contains the git sha that triggered said update. The configloading in turn will pick it up if present. This allows components to include the config version in their logs, which can be useful for debugging.
714e9a2
to
199bb86
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems safe to me. Could make it PROW-VERSION
or something if this ends up breaking something.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, stevekuznetsov The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This change makes the configupdater always add a key named VERSION to
the configmap which contains the git sha that triggered said update.
The configloading in turn will pick it up if present. This allows
components to include the config version in their logs, which can be
useful for debugging.
The second commit shows the reason I started thinking about this, namely the fact that the statusreconciler log is near useless, it tells us what it did but not for what config version, which makes debugging issues impossible and forces us to guess (ref #20498 (comment))
This is technically a breaking change in that we now always include a key in the configmaps that we didn't include before (but won't override if it gets populated). This is fine for prow itself, as it only looks at all files in the context of job configs and there it ignores files that do not end with
.yaml
or.yml
:test-infra/prow/config/config.go
Line 1026 in 6a328db
If someone uses the configupdater for something other than the prow config and then looks at all files and expects all of them to have a certain format, that would break now. But this seems rather unlikely to me. WDYT @fejta ?
/assign @fejta