Org: Changing default branch names to `main`

Created on 24 Sep 2020 · 31Comments · Source: kubernetes/org

Organization or repository

All

Users affected

Global

Describe the issue

This is a long-term tracking issue for renaming the default branch on repositories from master to main. Consider this community tracking for the discussion in https://github.com/github/renaming.

As of today (9/24):

Starting on October 1, 2020: newly-created repositories will default to main: https://github.com/github/renaming#on-october-1-2020-newly-created-repositories-will-default-to-main
If you are a maintainer of an existing repo, do NOT rename your existing default branch
- We're waiting for later in the year when the change will be less disruptive for consumers: https://github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-

cc: @kubernetes/owners @kubernetes/wg-naming
/area github-admin
/sig contributor-experience
/wg namin

aregithub-management lifecyclfrozen prioritimportant-longterm sicontributor-experience sirelease sitesting wnaming

Source

justaugustus

Most helpful comment

slightly related ... houndd uses the following to look for master/main ( added in https://github.com/hound-search/hound/pull/345 )

git remote show origin | grep "HEAD branch"

dims on 24 Feb 2021

👍3

All 31 comments

/wg naming

justaugustus on 24 Sep 2020

/sig testing

spiffxp on 24 Sep 2020

@justaugustus – Do you think this merits a communication to k/dev?

celestehorgan on 25 Sep 2020

/assign
cc: @liggitt

justaugustus on 29 Sep 2020

@justaugustus – Do you think this merits a communication to k/dev?

@nikhita's initial note to k-dev should suffice at this stage: https://groups.google.com/g/kubernetes-dev/c/jvRPIscaDek/m/1KWEUYXDBQAJ.

justaugustus on 29 Sep 2020

The only impact I can think of for new repos would be that the git.k8s.io redirector (http://git.k8s.io/$repo/$path going to https://github.com/kubernetes/$repo/tree/master/$path, e.g. http://git.k8s.io/community/sig-apps) would not work properly.

liggitt on 30 Sep 2020

Starting on October 1, 2020: newly-created repositories will default to main: https://github.com/github/renaming#on-october-1-2020-newly-created-repositories-will-default-to-main

Just to ensure we are on the same page - when we create a new repo in a Kubernetes org after Oct 1, we will set the default branch to master for now, correct? IIUC we'll move _all_ our repos to the main default branch once GitHub solves the issues listed here - https://github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-

nikhita on 30 Sep 2020

👍1

xref https://github.com/kubernetes/website/issues/21749 - k/website issue about changing their default branch to live

nikhita on 30 Sep 2020

The only impact I can think of for _new_ repos would be that the git.k8s.io redirector (http://git.k8s.io/$repo/$path going to https://github.com/kubernetes/$repo/tree/master/$path, e.g. http://git.k8s.io/community/sig-apps) would not work properly.

I think this has been handled by their default redirect: https://github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch/

It does mean things would be redirected twice, but that's probably the best scenario for the interim till everything has been switched over.

mrbobbytables on 30 Sep 2020

I think this has been handled by their default redirect: https://github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch/

I'm not sure... that seems to only apply to deleted branches. A new repo that only had a main branch would not have a deleted master branch that would trigger that, right?

liggitt on 30 Sep 2020

The only impact I can think of for new repos would be that the git.k8s.io redirector (http://git.k8s.io/$repo/$path going to https://github.com/kubernetes/$repo/tree/master/$path, e.g. http://git.k8s.io/community/sig-apps) would not work properly.

I think we should flip the default branch for _all_ repos at once. We'll also need to update our automation (prow, etc). For git.k8s.io specifically, we'll need to update:

https://github.com/kubernetes/k8s.io/blob/08581c1cd0937d893f0d1ffdfec8ceb8d7aa8356/k8s.io/configmap-nginx.yaml#L215-L223

nikhita on 30 Sep 2020

I'm not sure... that seems to only apply to deleted branches. A new repo that only had a main branch would not have a deleted master branch that would trigger that, right?

You're right. GitHub has confirmed it as well 👍

As just about all our repos are generated off the kubernetes-template-project, they will have a default branch name of master unless we change it there.

I think we should flip the default branch for _all_ repos at once. We'll also need to update our automation (prow, etc). For git.k8s.io specifically, we'll need to update:

Before flipping I do think we should test. It will mean the redirector won't work for the ones we do decide to test, but I think thats an acceptable trade-off for now.

mrbobbytables on 30 Sep 2020

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 on 29 Dec 2020

/remove-lifecycle stale

On Tue, Dec 29, 2020 at 8:39 PM fejta-bot notifications@github.com wrote:

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
https://github.com/fejta.
/lifecycle stale

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/org/issues/2222#issuecomment-752113489,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD24BUHFIWCHZIRQAX6ITVLSXHWJ3ANCNFSM4RYQRYHQ
.

nikhita on 30 Dec 2020

/priority important-longterm
/lifecycle frozen

spiffxp on 28 Jan 2021

Pulling out of slack

Heads up a word from GitHub on the branch rename, it can cause your CI checks to run again during the migration

their current best practice is to turn off CI till things are migrated and then turn it back on

Implied: this is a non-starter for us. For example, if we were to migrate kubernetes/kubernetes right now, the 980 currently open PR's would all re-trigger at once, which is well beyond our CI's capacity.

spiffxp on 28 Jan 2021

We're going to need to consider prow changes and how to coordinate them for this. Hopefully it is a matter of config-only changes + a few weeks of babysitting.

Off the top of my head, some things to consider:

post-rename, branch_protector may try to recreate master protection, delete main protection
presubmits/postsubmits should be updated to listen to both master/main branches
job authors need to ensure they're not explicitly checking out 'master'
renaming presubmits that have 'master' in their name will rely on status-reconciler to rename PR status contexts, this higher level of usage may expose some bugs (I've seen it fail to rename once recently, ref: https://github.com/kubernetes/test-infra/pull/20498#issuecomment-763087039)

To assess risk / scope of impact, I'm willing to trial the following repos (I'm an active owner / contributor, and they have presubmits/postsubmits/periodics all driven off of master):

kubernetes/k8s.io: https://github.com/kubernetes/k8s.io/issues/1597
kubernetes/org: https://github.com/kubernetes/org/issues/2466

Other possible repos (I'm less of an active contributor, but they are less community-blocking):

kubernetes-sigs/boskos
kubernetes-sigs/kubetest2

spiffxp on 28 Jan 2021

/sig release
/area release-eng
Tagging for SIG Release as well, to consider the implications / planning necessary for kubernetes/kubernetes

spiffxp on 28 Jan 2021

@spiffxp: The label(s) area/release-eng cannot be applied, because the repository doesn't have them

In response to this:

/sig release
/area release-eng
Tagging for SIG Release as well, to consider the implications / planning necessary for kubernetes/kubernetes

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.

k8s-ci-robot on 28 Jan 2021

@justaugustus mentioned on slack that he's looking at trialing:

kubernetes/sig-release
kubernetes/enhancements

spiffxp on 28 Jan 2021

@BenTheElder is interested in doing this for:

kubernetes-sigs/kind

spiffxp on 11 Feb 2021

Work needed to support moves of larger repos / repos with lots of jobs

https://github.com/kubernetes/test-infra/issues/20667 - prowjobs: allow pod-utils to use default remote branch instead of explicitly specifying
https://github.com/kubernetes/test-infra/issues/20672 - prowjobs: allow bootstrap-based jobs to use default remote branch instead of defaulting to master
https://github.com/kubernetes/test-infra/issues/20829 - prow: avoid retriggering presubmits on default remote branch rename

Based on lessons learned:

from moving kubernetes/org: https://github.com/kubernetes/org/issues/2466#issuecomment-770078738
from moving kubernets/k8s.io: TBD

spiffxp on 24 Feb 2021

slightly related ... houndd uses the following to look for master/main ( added in https://github.com/hound-search/hound/pull/345 )

git remote show origin | grep "HEAD branch"

dims on 24 Feb 2021

👍3

Created https://github.com/kubernetes/community/pull/5609 to add docs for repos (without too much traffic) that wish to migrate the default branch from master to main

nikhita on 7 Mar 2021

👍1

I intend to give this a shot in KIND the next week or two (want to catch up on some old PRs that have already had a rough time and get those closed out first), will keep an eye on https://github.com/kubernetes/community/pull/5609 first.