Automated semantic version tagging

[jpbetz]

We need better semver tag management for this repo.

I just manually tagged v4.6.0 from the command line directly from git. I could not find any scripts or automation to help ensure the tagging happens as intended. I think I might be the only person able to perform this task, which I don't love.

Having process/automation around tagging feels needed. I haven't thought carefully about how that should work and am open to suggestions (scripts to help perform the task or automation triggered when PRs are merged..).

[jpbetz]

@BenTheElder do you happen to know if any community repos have automation/scripting/tooling around git semver tagging?

@yongruilin as a potential future task. I can help but notice that apidiff could, in theory, be used to know if the version bump should be patch, minor or major version bump.

[BenTheElder]

@BenTheElder do you happen to know if any community repos have automation/scripting/tooling around git semver tagging?

AFAIK we do not, some repos have automation for cutting the binaries etc but not for determining when to introduce a tag.

Usually there are a few admins for the repo that have push access to push tags, and then the rest after that may or may not be automated.

Also, automation of github in general is challenging because we either:

• use github actions (newer), except the kubernetes github admin team disabled write permissions org wide due to various security footguns
• user our own robot accounts
  • these could be shared, but then you are increasing the security blast radius on an account compromise a lot if they're doing things like releasing, ... and also they have limited API quota, so even without security issues this doesn't scale well
• create an account per project ... except new robot-like accounts tend to get flagged, and we have all the logistical overhead of managing the accounts and plumbing them through to CI
• use github applications (similar to user accounts, bit of a pain to set one of these up for every repo, but don't share very well)

Personally, I write some human invoked scripts based around what the project needs.
Even k/k looks like "automated, but human triggered"

[BenTheElder]

I just manually tagged v4.6.0 from the command line directly from git. I could not find any scripts or automation to help ensure the tagging happens as intended. I think I might be the only person able to perform this task, which I don't love.

Note that this means even if we had automation, if the automation fails, you're the only person that can work around that.¹

I would personally suggest adding more maintainers and just coming to an agreement about what releasing looks like.

What I usually do is ensure that maintainers explicitly set git remote set-url upstream --push no_push and then explicitly push tags like git push ${URI} ${TAG} (without relying on a remote).

@yongruilin as a potential future task. I can help but notice that apidiff could, in theory, be used to know if the version bump should be patch, minor or major version bump.

This can only work accurately if you never make any breaking changes internally and instead only consider changes that alter the API signatures. I'm not certain about this project, but for most projects I don't think that's an adequate consideration of versions, in many cases the user-facing API shape doesn't change but there's some breaking behavioral change?

Footnotes

1. we can break-glass sort out adding someone else via kubernetes/org, but potentially that has pretty major latency. ↩

[jpbetz]

Thanks @BenTheElder! Maybe the answer is we add a script that makes this slightly safer for human triggered. Probably just need to make sure the tag is not malformed (it's a valid semver) and it's a valid next version (next major, minor or patch version).

[BenTheElder]

Thanks @BenTheElder! Maybe the answer is we add a script that makes this slightly safer for human triggered. Probably just need to make sure the tag is not malformed (it's a valid semver) and it's a valid next version (next major, minor or patch version).

I think this plus the tagging / pushing would be great!

FWIW one thing I've done so far in kind is have the release script only print commands to copy/paste for anything that actually touches upstream, so a human gets the final say kinda opposite this. In case there's a bug in the script I don't want it silently force-pushing over upstream in a surprising way, but I've personally been pretty happy with "script does everything locally and then prints out the potentially dangerous commands along with instructions"

hack/release/create.sh in sigs.k8s.io/kind

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[yongruilin]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten