Update base branch in each repo

[jillr]

SUMMARY

We've agreed that we want the collections we manage to use main as a default/base branch. Each collection will need to update their repos on GitHub, in any places where the default branch is referenced (docs, CI scripts, GitHub actions, etc ), redirect PRs, and notify their communities of the change. A how-to has been started and a blog post for the community will be going up soon.

I'm sure I missed some collections, but a partial list includes:

meta & Infrastructure repos

• ansible-build-data
• antsibull
• antsibull-changelog
• collection_template
• internal_test_tools
• overview (this repo)

Collection repos

• amazon.aws
• ansible.netcommon
• ansible.posix
• ansible.vmware_rest
• ansible.windows
• arista.eos
• cisco.asa
• cisco.ios
• cisco.iosxr
• cisco.nxos
• community.asa
• community.aws
• community.crypto
• community.general
• community.kubernetes
• community.network
• community.proxysql
• community.vmware
• community.windows
• community.sops
• community.zabbix
• frr.frr
• ibm.qradar
• junipernetworks.junos
• openvswitch.openvswitch
• splunk.es
• symantec.epm
• vmware.vmware_rest
• vyos.vyos

ISSUE TYPE

• Bug Report

[maxamillion]

I was talking to @pabelanger about this on irc and we'll likely need to coordinate this in some way so that we can plan an outage for the CI system(s) to deal with the switch or else a lot of moving parts will be intermittently broken because of the change in branch reference.

[geerlingguy]

For the community.kubernetes collection, since it's not using Zuul for CI, I think it will not need to be coordinated with the others—however I did have the practical question of whether my order of operations is correct:

1. Create new main branch (off current master).
2. Push new main branch to GitHub.
3. Switch all code references and CI references in the next commit to the main branch, and ensure it all works.
4. In GitHub's UI, switch the default branch from master to main.
5. Delete the master branch(?)

It's point 5 that I'm most worried about—could this cause any issues for people with existing forks or PRs (e.g. would every open PR need to be re-created—all the open PRs are currently against master?), or would any kind of special history be lost if we delete it? Is there any concern with it sticking around vs being deleted?

[gundalow]

For repos not using Shippable we could hold off from deleting master and either

1. make it readonly
2. keep it in sync with main

[jillr]

@geerlingguy It shouldn't cause immediate issues for people with forks, though they will need to update their forks/local checkouts to pull from the new branch. PRs will need to be updated. There's more detailed steps in the wiki (improvements welcome!) and this should do for programmatically targeting open PRs (I haven't fully tested that yet, YMMV). We have a blog post written (waiting on approvals) that to communicate these changes to the community.

[pabelanger]

I was talking to @pabelanger about this on irc and we'll likely need to coordinate this in some way so that we can plan an outage for the CI system(s) to deal with the switch or else a lot of moving parts will be intermittently broken because of the change in branch reference.

I've started the first step to automate this for collections in zuul. Today, most of the repo settings are managed via gitops using the following file: https://github.com/ansible/project-config/blob/master/github/projects.yaml#L15 Now, there is a setting to control the default-branch.

This is something I've been working for some time, to drop humans from having direct admin access to repos in github, but there is still bits that are manually managed (like branch protections). I'll be working with each project owner, @maxamillion to start and confirm the rename works. Once done, we can document the process and have owners just open PRs to renames and have automation handle it.

[maxamillion]

@jillr ansible.posix has completed the move to main and we've confirmed Zuul functionality -> ansible/project-config#544 ansible-collections/ansible.posix#66 ... I don't appear to have permission to edit the issue ticket to put a little check box next to the collection so I'm dropping the comment here. :)

[jborean93]

@jillr both ansible.windows and community.windows were done yesterday, CI is working in Shippable and codecov is reporting the coverage correctly.

[maxamillion]

@jillr ibm.qradar and splunk.es have completed the migration to main

[jillr]

@maxamillion @pabelanger @jborean93 @geerlingguy @gundalow @felixfontein There was a case on community.aws where an open PR was not actually migrated over with the script, so when master was deleted it was closed. You may want to go through recently closed PRs in each repo you've updated and ensure that didn't happen to anything. To fix it I just had to temporarily created a master branch, reopen the PR, move it over to main, and re-delete master.

If anyone wants to work together on whatever repo gets updated next so we can add some additional checks and error handling to the script I'm happy to help.

[felixfontein]

@jillr I checked community.crypto, community.general and community.network, there was no PR closed on the day I retargeted the PRs with the script. So whatever it was, it didn't affect these repos.

[jillr]

Oh, and we should also update this repo! I missed that. cc @gundalow

[felixfontein]

I guess we need to keep the master branch for this repo for some time, because there are a lot of links to it. How about replacing the files in it with short stubs which point to the correct ones, i.e. the ones in main branch, once the main branch exists?

[jillr]

Oops, we forgot to come back and close out this ticket! There is no ansible.vmware_rest collection (the vmware.vmware_rest collection was in active development when we started this ticket and there were still some open design questions). I'm not aware of any repos that still need this change. If any come up they can be brought up at the D&I WG meeting that will be kicking off in the next few weeks (doodle poll for times here) or in #ansible-diversity on Freenode IRC.