point arch migrator files to new subfolder in pinning (#2640)

* replace remaining uses of `master` branch

* point arch migrator files to new subfolder in pinning

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* fix: one more link

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: beckermr <becker.mr@gmail.com>

Author: 3 people

blog/2020-10-29-macos-arm64.md

@@ -107,7 +107,7 @@ bootstrapper.
 
 All the below changes will be done by a bot and the packages the bot
 will send PRs to is determined by the list of packages at
-[conda-forge-pinning](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/osx_arm64.txt)
+[conda-forge-pinning](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/migration_support/osx_arm64.txt)
 and their dependences. If you would like to add support, please send a
 PR adding the feedstock name to the above list. After that PR is merged,
 you can monitor the status at [conda-forge

docs/maintainer/adding_pkgs.md

@@ -64,7 +64,7 @@ There are, currently, three ways to generate a recipe:
    You do _not_ necessarily have to use `grayskull`, and the recipes produced by `grayskull` might need to be reviewed and edited.
    Read more about `grayskull` and how to use it [here](https://github.com/conda-incubator/grayskull#introduction).
 
-3. If it's none of the above, generate a recipe with the help of [the example recipe](https://github.com/conda-forge/staged-recipes/tree/master/recipes/example) in the [staged-recipes repository](https://github.com/conda-forge/staged-recipes) and modify it as necessary.
+3. If it's none of the above, generate a recipe with the help of [the example recipe](https://github.com/conda-forge/staged-recipes/tree/main/recipes/example) in the [staged-recipes repository](https://github.com/conda-forge/staged-recipes) and modify it as necessary.
 
 Your final recipe should have no comments (unless they're actually relevant to the recipe, and not generic instruction comments), and follow the order in the example.
 
@@ -91,7 +91,7 @@ In case you are building your first recipe using conda-forge, a step-by-step ins
 3. Checkout a new branch from the staged-recipes `main` branch.
 4. Through CLI, cd inside the ‘staged-recipes/recipes' directory.
 5. Within your forked copy, create a new folder in the recipes folder for your package (i.e, `...staged-recipes/recipes/<name-of-package>`)
-6. Copy [meta.yaml](https://github.com/conda-forge/staged-recipes/blob/master/recipes/example/meta.yaml) from the example directory.
+6. Copy [meta.yaml](https://github.com/conda-forge/staged-recipes/blob/main/recipes/example/meta.yaml) from the example directory.
    All the changes in the following steps will happen in the COPIED meta.yaml (i.e., `...staged-recipes/recipes/<name-of-package>/meta.yaml`).
    Please leave the example directory unchanged!
 7. Modify the copied recipe (meta.yml) as needed. To see how to modify meta.yaml, take a look at
@@ -469,7 +469,7 @@ It is therefore crucial to ensure that only library versions with a compatible [
 
 In the best case, the shared library you depend on:
 
-- defines a pin in the [list of globally pinned packages](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml)
+- defines a pin in the [list of globally pinned packages](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml)
 - exports its [ABI](../glossary.md#abi) compatible requirements by defining `run_exports` in it's meta.yaml
 
 In these cases you do not have to worry about version requirements:

docs/maintainer/guidelines.md

@@ -100,7 +100,7 @@ Sometimes, packages are misnamed.
 To correct the name of the package, please submit a PR into [staged-recipes](https://github.com/conda-forge/staged-recipes) with the correct name.
 During the review process, please make certain to note that the package is renamed and contact a member of conda-forge/core to remove the old feedstock (and potentially package, if needed).
 
-Occasionally, the .gitmodules file in the [feedstocks](https://github.com/conda-forge/feedstocks/blob/master/.gitmodules) needs to be updated to remove the old feedstock.
+Occasionally, the .gitmodules file in the [feedstocks](https://github.com/conda-forge/feedstocks/blob/main/.gitmodules) needs to be updated to remove the old feedstock.
 It's not entirely clear what those circumstances are.
 See [conda-forge.github.io#1070](https://github.com/conda-forge/conda-forge.github.io/issues/1070).
 

docs/maintainer/infrastructure.md

@@ -122,8 +122,8 @@ Instead, it has its own Azure Pipelines workflow and a well-documented README.
 
 - ⚙️ Deployed manually from [`conda-forge/msys2-recipes`](https://github.com/conda-forge/msys2-recipes)
 
-This is a fork of the old community recipes repository at Anaconda, which includes the `msys2` recipes under the [`msys2/`](https://github.com/conda-forge/msys2-recipes/tree/master/msys2) directory.
-Note also the supporting scripts in the [`common-scripts/`](https://github.com/conda-forge/msys2-recipes/tree/master/common-scripts) folder.
+This is a fork of the old community recipes repository at Anaconda, which includes the `msys2` recipes under the [`msys2/`](https://github.com/conda-forge/msys2-recipes/tree/main/msys2) directory.
+Note also the supporting scripts in the [`common-scripts/`](https://github.com/conda-forge/msys2-recipes/tree/main/common-scripts) folder.
 
 ### Website
 
@@ -156,7 +156,7 @@ Hosts the global pinnings for conda-forge, and the ongoing migrations.
 - ⚙️ Deployed in [Anaconda.org](https://anaconda.org/conda-forge/conda-forge-pinning) via [`conda-forge/conda-forge-pinning-feedstock`](https://github.com/conda-forge/conda-forge-pinning-feedstock)
 - 🔒 Has access to Azure, Anaconda.org (cf-staging)
 
-Package-wide dependency pins are defined in [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml) in the [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock).
+Package-wide dependency pins are defined in [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml) in the [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock).
 
 For more information on conda-forge wide package pins, please refer to [Globally pinned packages](pinning_deps.md#globally-pinned-packages).
 
@@ -245,7 +245,7 @@ Bugs or suggestions regarding the service functionality should therefore be open
 The code and logic behind [`autotick-bot`](#autotick-bot).
 
 - 📜 Source at [`regro/cf-scripts`](https://github.com/regro/cf-scripts)
-- 📖 [Documentation](https://github.com/regro/cf-scripts/blob/master/README.md)
+- 📖 [Documentation](https://github.com/regro/cf-scripts/blob/main/README.md)
 
 ### Automated maintenance
 
@@ -474,8 +474,8 @@ same is described below:
 - Get in touch with `conda-forge/core` to discuss your use case. This can be done with an issue in the relevant feedstock or via [Zulip](https://conda-forge.zulipchat.com).
 - Once discussed, share credentials for a supported cloud with a `conda-forge/core` member, so that it can be added to conda-forge's Cirun account, alternatively
   the user can sponsor cloud credits for an existing conda-forge's cloud account.
-- Add configuration for the runner's virtual machine in [`conda-forge/.cirun`](https://github.com/conda-forge/.cirun/blob/master/.cirun.global.yml)
-  add a policy entry in [`.access.yml`](https://github.com/conda-forge/.cirun/blob/master/.access.yml) to allow access to the runner for
+- Add configuration for the runner's virtual machine in [`conda-forge/.cirun`](https://github.com/conda-forge/.cirun/blob/main/.cirun.global.yml)
+  add a policy entry in [`.access.yml`](https://github.com/conda-forge/.cirun/blob/main/.access.yml) to allow access to the runner for
   a feedstock.
 - Add the labels defined above in your `<package-feedstock>/recipe/conda_build_config.yaml`, under `github_actions_labels` and re-render the
   feedstock. See links below for some examples.
@@ -619,7 +619,7 @@ can be specified as arguments to the `{{ compiler(...) }}` macro:
 - `go-cgo` and `go-nocgo`; see [Go packages](/docs/maintainer/example_recipes/go/)
 
 The authoritative source of the current compilers and versions for various languages
-and platforms is the [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml) file
+and platforms is the [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml) file
 in the [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock) repository
 as described in [Globally pinned packages](pinning_deps.md#globally-pinned-packages).
 

docs/maintainer/knowledge_base.md

@@ -2040,7 +2040,7 @@ If a feedstock does need access to additional resources (like GPUs), please see
 
 #### `nvcuda.dll` cannot be found on Windows
 
-The [scripts](https://github.com/conda-forge/conda-forge-ci-setup-feedstock/blob/master/recipe/install_cuda.bat)
+The [scripts](https://github.com/conda-forge/conda-forge-ci-setup-feedstock/blob/main/recipe/install_cuda.bat)
 used to install the CUDA Toolkit on Windows cannot provide `nvcuda.dll`
 as part of the installation because no GPU is physically present in the CI machines.
 As a result, you might get linking errors in the postprocessing steps of `conda build`:
@@ -2122,7 +2122,7 @@ To request a migration for a particular package and all its dependencies:
 2. Check the feedstock in question to see if there is already an issue or pull request.
    Opening an issue here is fine, as it might take a couple iterations of the below,
    especially if many dependencies need to be built as well.
-3. If nothing is under way, look at the current [conda-forge-pinning](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/osx_arm64.txt).
+3. If nothing is under way, look at the current [conda-forge-pinning](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/migration_support/osx_arm64.txt).
 4. If the package is not listed there, make a PR, adding the package
    name to `osx_arm64.txt` (preserving the alphabetical ordering).
    The migration bot should start making automated pull requests to the
@@ -2295,7 +2295,8 @@ To reset your feedstock token and fix issues with uploads, follow these steps:
 
 You can add a feedstock to `arch_rebuild.txt` if it requires rebuilding with different architectures/platforms (such as `ppc64le` or `aarch64`).
 Check the [migration status](https://conda-forge.org/status/#aarch64andppc64leaddition) to see if your package is already in the queue to get migrated.
-If not, you can add the feedstock to `arch_rebuild.txt` by opening a PR to the [conda-forge-pinning-feedstock repository](https://github.com/conda-forge/conda-forge-pinning-feedstock).
+If not, you can add the feedstock to [`arch_rebuild.txt`](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/migration_support/arch_rebuild.txt)
+by opening a PR to the [conda-forge-pinning-feedstock repository](https://github.com/conda-forge/conda-forge-pinning-feedstock).
 Once the PR is merged, the migration bot goes through the list of feedstocks in `arch_rebuild.txt` and opens a migration PR for any new feedstocks and their dependencies, enabling the aarch64/ppc64le builds.
 
 <a id="migrations-and-migrators"></a>
@@ -2307,7 +2308,7 @@ Once the PR is merged, the migration bot goes through the list of feedstocks in
 When any changes are made in the global pinnings of a package, then the entire stack of the packages that need that package on their `host` section would need to be updated and rebuilt.
 Doing it manually can be quite tedious, and that's where migrations come to help. Migrations automate the process of submitting changes to a feedstock and are an integral part of the `regro-cf-autotick-bot`'s duties.
 
-There are several kinds of migrations, which you can read about in [Making Migrators](https://github.com/regro/cf-scripts/blob/master/README.md#making-migrators). To generate these migrations, you use migrators, which are bots that automatically create pull requests for the affected packages in conda-forge.
+There are several kinds of migrations, which you can read about in [Making Migrators](https://github.com/regro/cf-scripts/blob/main/README.md#making-migrators). To generate these migrations, you use migrators, which are bots that automatically create pull requests for the affected packages in conda-forge.
 To propose a migration in one or more pins, the migrator issues a PR into the pinning feedstock using a yaml file expressing the changes to the global pinning file in the migrations folder.
 Once the PR is merged, the dependency graph is built. After that, the bot walks through the graph, migrates all the nodes (feedstocks) one by one, and issues PRs for those feedstocks.
 

docs/maintainer/pinning_deps.md

@@ -19,7 +19,8 @@ Especially widely used libraries with restricted version compatibilities increas
 By fixing crucial libraries to specific dependency version shared by all packages in conda-forge, we avoid fractioning of our packages in incompatible islands.
 The following paragraphs give a short introduction about how this global version pinning is realized in conda-forge.
 
-The current versions of globally pinned packages are defined in the [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml) file located in the `conda-forge-pinning` feedstock.
+The current versions of globally pinned packages are defined in the [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml)
+file located in the `conda-forge-pinning` feedstock.
 These pinned versions represent the ABIs that conda-forge is currently supporting, with almost all available packages built against that version.
 
 When a rerendering happens, conda-smithy will render the recipe using conda-build and output configuration files for each job and save them in a yaml file in `.ci_support` folder. For example, there's an output configuration file for each OS, each python version, etc.
@@ -67,7 +68,8 @@ When there's a new ABI version of gmp (say 7.0), then conda-forge-pinning will b
 
 :::
 
-If a package is not pinned in [conda-forge-pinning](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml), then the pinning needs to be done manually. If the package is a `C/C++` library with a `C/C++` API that is consumed and linked to by other libraries, then that package is a candidate to be added to `conda-forge-pinning`. Please open an issue in [conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock) for discussion.
+If a package is not pinned in [conda-forge-pinning](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml),
+then the pinning needs to be done manually. If the package is a `C/C++` library with a `C/C++` API that is consumed and linked to by other libraries, then that package is a candidate to be added to `conda-forge-pinning`. Please open an issue in [conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock) for discussion.
 
 :::note
 
@@ -110,7 +112,7 @@ For example, numpy may be used either as a python package, and it also has a C l
 The former usage would not require `run_exports`, but the latter would.
 
 In this scenario, it may be advantageous to split the package into distinct metapackages that may share a common parent containing the actual files, but with each metapackage defining different pinning behavior.
-Anaconda does this for numpy (see the [recipe](https://github.com/AnacondaRecipes/numpy-feedstock/blob/master/recipe/meta.yaml)).
+Anaconda does this for numpy (see the [recipe](https://github.com/AnacondaRecipes/numpy-feedstock/blob/main/recipe/meta.yaml)).
 
 The general idea is that the `numpy-devel` package should be used when a package is building against the C interface (i.e. it needs the compatibility bound), and the numpy package should be used when a package is using only the python interface.
 
@@ -135,7 +137,8 @@ for the affected packages in conda-forge.
 Usually, the bot will generate these migrations automatically. However, when a pin is first made or added, one may need to
 be added by hand. To do this, follow these steps:
 
-1. Create a new migration yaml by copying [example.exyaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/example.exyaml) in the `conda-forge/conda-forge-pinning` repository.
+1. Create a new migration yaml by copying [example.exyaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/migrations/example.exyaml)
+   in the `conda-forge/conda-forge-pinning` repository.
 2. Change the migration yaml to reflect the package and version to be migrated
 3. Write a migrator for propagating the pin changes.
 4. Propose the changes as a [PR](../glossary.md#pr) to [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock).
@@ -146,5 +149,5 @@ be added by hand. To do this, follow these steps:
      - Update the version in conda_build_config.yaml
      - Bump the version in meta.yaml to the current date
 
-Details of how the migration yaml is setup are provided in an [example](https://github.com/conda-forge/conda-forge-pinning-feedstock/tree/master/recipe/migrations/example.exyaml)
-and documentation [here](https://github.com/regro/cf-scripts/blob/master/README.md#making-migrators).
+Details of how the migration yaml is setup are provided in an [example](https://github.com/conda-forge/conda-forge-pinning-feedstock/tree/main/recipe/migrations/example.exyaml)
+and documentation [here](https://github.com/regro/cf-scripts/blob/main/README.md#making-migrators).

docs/maintainer/understanding_conda_forge/feedstocks.md

@@ -182,4 +182,4 @@ sequenceDiagram
 ```
 
 Migrators are a powerful mechanism that can do almost arbitrary recipe changes.
-They are written in Python and the current set of migrators can be found in the [`regro/cf-scripts` repository](https://github.com/regro/cf-scripts/tree/master/conda_forge_tick/migrators).
+They are written in Python and the current set of migrators can be found in the [`regro/cf-scripts` repository](https://github.com/regro/cf-scripts/tree/main/conda_forge_tick/migrators).

docs/maintainer/updating_pkgs.md

@@ -76,7 +76,8 @@ When a new version of a package is released on PyPI/CRAN/.., we have a bot that
 
 ##### **How does regro-cf-autotick-bot create automatic version updates?**
 
-The [regro-cf-autotick-bot](https://github.com/regro/autotick-bot) continuously searches on a loop for any PyPI releases, GitHub releases, and any other sources of versions when any updates are released. The source code that gets executed in the loop comes from the [cf-scripts repository](https://github.com/regro/cf-scripts), which contains the code to detect versions and submit PRs. Visit [cf-scripts](https://github.com/regro/cf-scripts/blob/master/README.md) to read more about it.
+The [regro-cf-autotick-bot](https://github.com/regro/autotick-bot) continuously searches on a loop for any PyPI releases, GitHub releases, and any other sources of versions when any updates are released. The source code that gets executed in the loop comes from the [cf-scripts repository](https://github.com/regro/cf-scripts), which contains the code to detect versions and submit PRs.
+Visit [cf-scripts](https://github.com/regro/cf-scripts/blob/main/README.md) to read more about it.
 
 The bot creates updates via inspection of the upstream release and will always update the `source` section and build version in the [recipe metadata](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#).
 As an experimental feature, the autotick bot can also be configured to verify or update the recipe's requirements for [Grayskull](https://github.com/conda-incubator/grayskull)-compatible recipes.