[krel] Allow krel to interpret an arbitrary k/release git reference instead of just branches (TOOL_BRANCH)

[justaugustus]

While debugging kubernetes/kubernetes#86182 and #1020, we ran a few mock stages and releases targeting anago against forks of k/release.

I noticed that it might've been nice to have more information available which fork and commit we were using at any one time, so a few suggestions:

• Allow krel to interpret a git ref (instead of just branch) for use as the release tools repo to checkout (changes to both krel and the gcb/{stage,release} configs)
  - Surface the release tool repo org, name, branch (if chosen), and git ref at the time of run as part of the anago session values

@tpepper -- Thoughts?

/help
/milestone v1.18
/sig release
/area release-eng
/priority important-soon

[k8s-ci-robot]

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

Please ensure the request meets the requirements listed here.

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

In response to this:

While debugging kubernetes/kubernetes#86182 and #1020, we ran a few mock stages and releases targeting anago against forks of k/release.

I noticed that it might've been nice to have more information available which fork and commit we were using at any one time, so a few suggestions:

• Allow anago to interpret a git ref (instead of just branch) for use as the release tools repo to checkout (changes to both anago and the gcb/{stage,release} configs)
• Surface the release tool repo org, name, branch (if chosen), and git ref at the time of run as part of the anago session values

@tpepper -- Thoughts?

/help
/milestone v1.18
/sig release
/area release-eng
/priority important-soon

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.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[justaugustus]

Let's consider this an eventual feature request for krel anago, not the shell-based tool.
/remove-lifecycle rotten
/milestone clear

[tpepper]

This could be emitting more info like git status and cat .git/config at anago runtime.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[markjacksonfishing]

/remove-lifecycle stale

[saschagrunert]

@justaugustus is this something we still need? We drastically changed the logging approach in krel stage/release. For example the --log-level=debug output will implicitly increase the git verbosity output, too.

[justaugustus]

@saschagrunert -- I think this might still be useful:

Allow anago to interpret a git ref (instead of just branch) for use as the release tools repo to checkout (changes to both anago and the gcb/{stage,release} configs)

s/anago/krel

AND

s/TOOL_BRANCH/TOOL_REF

thoughts?

[saschagrunert]

thoughts?

Yes, this seems straight forward to implement.

[justaugustus]

updated the issue title

[cpanato]

/assign