Open saschagrunert opened 10 months ago
@cpanato volunteered to work on this
/assign @cpanato
this will require some code changes I will start working on this part
not yet done /reopen
@cpanato: Reopened this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
There is a sync job in place which fast-forwards the kubernetes/kubernetes
release-1.x
branch frommaster
until the final (non-prerelease) tag exists on it. The job runs periodically in prow and does basically nothing when we're not in code freeze: https://testgrid.k8s.io/sig-release-releng-blocking#git-repo-kubernetes-fast-forwardThe idea is to re-use the logic for other repositories like
k/website
to sync the documentation development branch during the release cycle. We have to make the tool more flexible from a CLI perspective and double check the code paths for possible adaptations.The entrypoint for the code of
krel fast-forward
is there: https://github.com/kubernetes/release/blob/master/cmd/krel/cmd/ff.go