ci: archive dead release branches 0.4-0.57 (VEP #233)

[dhiller]

Summary

Archive release branches release-0.4 through release-0.57 in kubevirt/kubevirt as described in VEP #233 transition plan point 4.

These branches have been de facto dead for years. This PR:

• Removes 25 presubmit CI job YAML files for release branches 0.13-0.57 (~33,400 lines)
• Sets unmanaged: true in the Prow branch-protection config for all 50 branches (release-0.4 through release-0.57), preventing the branchprotector from managing them
• Cleans up stale config entries for non-existent branches release-0.25 and release-0.28 (Travis CI contexts for branches that were never created)

Why unmanaged: true?

Prow's branchprotector does not support GitHub's lock_branch field. Since kubevirt/kubevirt has repo-level protect: true, the branchprotector manages ALL branches and would reset any manually-applied lock_branch: true on its hourly sync. Setting unmanaged: true opts these branches out, allowing a subsequent lock_branch API call (Phase 2) to persist.

Phase 2 (after this PR merges)

A one-time script will call the GitHub API to set lock_branch: true on all 50 branches, making them fully read-only.

Scope

• In scope: release-0.4 through release-0.57 (50 branches)
• Out of scope: release-0.58 and release-0.59 (will be handled by the normal EOL trigger at v1.10 GA)

Test plan

• Verify kubevirt-presubmits-0.58.yaml and kubevirt-presubmits-0.59.yaml are preserved
• Verify no references to non-existent branches (0.5, 0.7, 0.25, 0.28) in config
• After merge: verify branchprotector skips these branches on next hourly run
• After merge: run Phase 2 script to set lock_branch: true

Tracker: kubevirt/kubevirt#17717

🤖 Generated with Claude Code

[kubevirt-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[sourcery-ai]

Sorry, we are unable to review this pull request

The GitHub API does not allow us to fetch diffs exceeding 20000 lines

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign enp0s3 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gemini-code-assist]

Code Review

This pull request removes several Prow job configuration files, specifically presubmits definitions across various release branches (e.g., release-0.13 through release-0.50) and Kubernetes versions. This indicates a cleanup or restructuring of the CI/CD pipeline definitions. There are no review comments to address.

[lyarwood]

Summary

Archive release branches release-0.4 through release-0.57 in kubevirt/kubevirt as described in VEP #233 transition plan point 4.

https://github.com/kubevirt/enhancements/blob/2f5197b1b43877d0a4b5d5cefd511aa3048785f8/veps/sig-release/233-release-branch-eol-policy/vep.md?plain=1#L255-L259

@dhiller ah apologies I did include this as an initial immediate step in v1.9.0. Can I announce the approach first on the ML and maybe go ahead with this after CF later in the cycle?

[dollierp]

I would have used YAML anchors.

            release-0.4: &archived_branch
              unmanaged: true
            release-0.5: *archived_branch
            release-0.6: *archived_branch
            [...]

[dhiller]

Summary

Archive release branches release-0.4 through release-0.57 in kubevirt/kubevirt as described in VEP #233 transition plan point 4.

kubevirt/enhancements@2f5197b/veps/sig-release/233-release-branch-eol-policy/vep.md?plain=1#L255-L259

@dhiller ah apologies I did include this as an initial immediate step in v1.9.0. Can I announce the approach first on the ML and maybe go ahead with this after CF later in the cycle?

ack - again, I'd be happy to get your feedback whether this approach is good enough or we need to improve it.