moving from master to main mega-issue

to do:

• set current org-wide default to master for the time being so we don’t break anything
• move over non-feedstock repos/tools
  • conda-smithy (https://github.com/conda-forge/conda-smithy/pull/1500)
  • web services (https://github.com/conda-forge/conda-forge-webservices/pull/462, changed heroku too)
  • admin migrations (https://github.com/conda-forge/admin-migrations/pull/62)
  • admin requests (https://github.com/conda-forge/admin-requests/pull/300)
  • blog (https://github.com/conda-forge/blog/pull/46)
  • status page (https://github.com/conda-forge/status/commit/65b48a38641d0f588e283b8be08f1ce233948023)
  • docs (https://github.com/conda-forge/conda-forge.github.io/pull/1508)
  • status page CI counter thingy (https://github.com/conda-forge/conda-forge-webservices/pull/461)
  • cdt-builds (https://github.com/conda-forge/cdt-builds/pull/52)
  • cfep
  • feedstocks
  • feedstock-tokens
  • feedstock-outputs (https://github.com/conda-forge/feedstock-outputs/pull/23, https://github.com/conda-forge/conda-forge-webservices/pull/463, checked smithy and ci config as well)
  • staged-recipes (https://github.com/conda-forge/staged-recipes/pull/16094)
  • repodata-tools
  • repodata-shards
  • releases
  • artifact validation (https://github.com/conda-forge/artifact-validation/pull/545)
  • by-the-numbers (https://github.com/conda-forge/by-the-numbers/pull/16)
• figure out how to change github action workflow files and not cause rerendering issues
  • ~use ssh keys per feedstock~
  • ~have webservices add a github app token w/ workflows permissions per feedstock to its secrets before rerendering~
  • make an option in smithy and then use an admin migration
• formulate plan for how to switch over feedstocks
  • test github actions redirects (don’t work, going to move them and then make a tag called master)
  • move over github actions
    • automerge action (https://github.com/conda-forge/automerge-action/pull/2)
    • rerender action (https://github.com/conda-forge/webservices-dispatch-action/pull/12)
  • smithy
    • PR to smithy to fully handle branch changing (https://github.com/conda-forge/conda-smithy/pull/1501)
    • make a smithy release
  • make webservices completely agnostic
    • remove refs to master or add main (https://github.com/conda-forge/conda-forge-webservices/pull/467)
    • https://github.com/conda-forge/conda-forge-webservices/issues/468 (https://github.com/conda-forge/conda-forge-webservices/pull/469, https://github.com/conda-forge/conda-forge-webservices/pull/471)
  • make admin migrations agnostic (https://github.com/conda-forge/admin-migrations/pull/63)
  • make the bot agnostic (https://github.com/regro/cf-scripts/pull/1442)
  • enable bot to place keys in repo secrets (https://github.com/conda-forge/conda-forge-webservices/pull/478)
  • move workflows to main via admin migration (https://github.com/conda-forge/admin-migrations/pull/70)
  • add new workflow files to smithy (https://github.com/conda-forge/conda-smithy/pull/1554)
  • release smithy with new workflow files
  • ~[ ] turn on keys in webservices for rendering~ (not needed so didn’t do it)
  • make an announcement about move to main (https://github.com/conda-forge/conda-forge.github.io/pull/1609)
  • move over ci-scripts repo by hand
  • write admin migration to move the rest (this has to change upload_on_branch, the conda-forge.yml tooling branch name, and API calls to migrate the repo, see https://github.com/conda-forge/admin-migrations/pull/72)
  • move over feedstock generation (https://github.com/conda-forge/staged-recipes/pull/18311)
  • ~[ ] close out admin migration~ (not going to do this actually in case we unarchive things)
  • cleanup conda-forge/feedstocks from heroku errors (https://github.com/conda-forge/admin-migrations/pull/79)

notes:

• github is going to use main
• they plan to provide automated tooling later this year: https://github.com/github/renaming

x-ref: https://github.com/conda-forge/conda-forge.github.io/issues/1099

[chrisburr]

To get the readme full updated, we’d have to rerender. However, the master links should forward.

I think that’s reasonable and arguably better as the Azure links won’t work properly until there is a build for the new main branch.

For the rest: I’m happy to support either option though if I had to pick I’d choose option 1.

[beckermr]

I’ve started in on doing this. A lot of our admin repos and whatnot can be moved by hand.