chore: migrate from master branch to main

[HonkingGoose]

Changes:

• master -> main for CI
• Replace links to renovatebot/renovate master to point to renovatebot/renovate main instead

Really rough draft to get an idea of the changes needed to migrate from master to main on this repo.

Maybe @rarkins can make a complete copy of this repo somewhere safe and try this out, and see where stuff breaks.
I have not tested this myself yet, as I would need to replicate the full setup that this repository has somehow (external bots, branch protection rules, semantic release bot, etc.)

I have also not replaced any mentions of master in the docs/usage section or in any fixtures or snapshots, as that pertains to the code of Renovate bot itself and what branches the bot supports on specific platforms.

Context:

Explore what changes we would probably need to migrate from master to main as the default branch on the renovatebot/renovate repository.

Closes #8153.

Also for more information read: https://github.com/github/renaming
GitHub docs also has some guidance on how to rename a branch from the interface as admin: https://docs.github.com/en/github/administering-a-repository/renaming-a-branch

Checklist:

GitHub should do the following for us automatically:

• GitHub will redirect any old links that target master to point to main
• GitHub Pages can build and deploy from any branch
• Migrate open PRs to target main instead of master
• Migrate branch protections rules that explicitly target master
• Contributors will get a prompt helping them to update their local Git configuration

What we need to do before migrating:

• Check if there's other external config for bots in use on this repo (bot dashboards, code-coverage bot etc.)
• Check if all the relevant CI files are correct for use with main

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added unit tests, or
• No new tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[viceice]

needs branch protection added for main, should be doable before exists

[HonkingGoose]

Yeah the branch protection rules for main should be setup before merging.

This is not strictly necessary according to: https://github.com/github/renaming/blob/main/README.md#renaming-existing-branches

[viceice]

Assuming you used search and replace ;)

[HonkingGoose]

I used the search function in VS Code, with the following settings:

Search for string master.
Files to exclude: __fixtures__, .spec.ts, __snapshots__

I've deliberately not touched any files in docs/usage for now, at least not where we explain any Renovate config stuff.

[HonkingGoose]

GitHub will migrate the branch protection rules automatically if you're doing the migration from master to main via the GitHub interface (see image): https://github.com/github/renaming/blob/main/README.md#renaming-existing-branches

[HonkingGoose]

Merged the latest master branch and resolved the merge conflict, that was caused by the newlines change in the label bot file: label-actions.yml. I've kept the newlines from master as having 2 newlines makes it so that the bot uses paragraphs.

[JamieMagee]

@HonkingGoose This looks ready for merge, right? But it should be manually merged by @rarkins, as there are manual steps to follow.

[HonkingGoose]

@JamieMagee Yeah I think this is ready for final review and merge.
Do you have any tips on the migration @JamieMagee?

The main idea, I think, would be to freeze everything, turn off all the bots, and migrate via GitHub interface, merge this PR, confirm tests work, and then enable bots one by one, with the Semantic Release bot as the last one to be re-enabled.

Proposed steps:

1. Stop manually merging things into master, (basically a full freeze).
2. Turn off all bots that do things on our master branch (Renovate bot, Semantic Release, other CI).
3. Use the GitHub interface to migrate from master to main.
4. Confirm branch protections are still good on main.
5. GitHub will re-target all open pull requests (including this one).
6. Merge this PR into main so that all the CI uses the new main branch.
7. Confirm branch status checks work properly again.
8. Turn on bots one by one (do Semantic Release bot last).

[JamieMagee]

That sounds like a comprehensive migration plan. Could I suggest one more thing: can we try this on one of the other repos first as a test run for the main renovate repository?

[rarkins]

Not sure semantic release needs to be turned off as long as we don't add any release-triggering commits to master/main?

And yes maybe let's do all the smaller repos first and finish with this one.

[HonkingGoose]

Could I suggest one more thing: can we try this on one of the other repos first as a test run for the main renovate repository?

Good idea! It's probably safer to try the smaller repos first, see if we've got all things covered, and as the last step migrate the main renovate repository.

Not sure semantic release needs to be turned off as long as we don't add any release-triggering commits to master/main?

I'm trying to make sure that we don't create releases unnecessarily. But if we don't use any fix: or feat: or refactor: commits we should probably be safe?

---

EDIT:

Also maybe we should turn of the Renovate auto-approve bots while we're migrating to main?
I guess they could cause "release-triggering" commits.

[rarkins]

I updated the renovatebot/pep440 repo to use main and it went smoothly. e.g. PRs in progress were retargeted, actions continued fine.

This guide for local development pops up:

[JamieMagee]

Time to do the other repos, followed by this one?

[viceice]

i think the v25 release will be a good point to switch to main

[HonkingGoose]

I've merged the latest changes from master into this branch as there were some changes related to making a build and release on the v24 branch that I needed to pull in.

I've fixed the "bad merge" in the .releaserc file (it had two objects keys for the branches object...). We now have one branches object with configuration for the v24 branch and the main branch.

This should be OK again, but please check my work.

[viceice]

needs update, maybe deconflicting 😉

[viceice]

new step popped up:

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

[renovate-release]

🎉 This PR is included in version 25.1.2 🎉

The release is available on:

• GitHub release
• 25.1.2

Your semantic-release bot 📦🚀

[HonkingGoose]

Well that went smoothly! The build still works, the semantic release bot kept humming along, and things were fine. 😄 🎉 ✨ ✨ ✨

Thank you @viceice, @rarkins and @JamieMagee for the reviews, tips and suggestions to get this landed. ❤️