Avoid arch migrator PRs to maintenance branches that already have the arches

[h-vetinari]

I thought the bot opened these just if there's non-empty diff, but it turns out it'll even open a PR for a completely empty diff, c.f. conda-forge/openjdk-feedstock#160 / conda-forge/openjdk-feedstock#161

On feedstocks where we regularly need to create new branches for LTS versions, this becomes annoying eventually (aside from wasting CI resources). It can also create confusion for people who deal with this less frequently

[beckermr]

This might be a bug related to the latest rerendering changes

[h-vetinari]

Thanks for the quick response! I only see permission-related bits in #2503 though, so I think that'll likely only cover the corner case mentioned in the OP (empty diff, presumably nonempty permission changes).

However, as soon as the creation of a maintenance branch causes any kind of rerendering change (which is very often the case, as the old state of the feedstock at which we branch is not often 100% up to date), it'll still causes new arch PRs.

Since the arch migrations are special anyway, I'd really like to avoid that case - e.g. we could check if there are already osx-arm64 files under .ci_support and abort if so.

In general, we could probably improve the situation around spurious PRs for all migrations (if we can spend the compute resources to rerender twice) as follows:

• Rerender feedstock first (to create baseline to compare against)
• Actually add the migrator file
• rerender again
  • if there's a diff, amend the previous rerender commit and open PR
  • if there's no diff, don't open a PR.

[beckermr]

Two rerenders will slow the bot down a ton and so is not feasible at the moment.

[h-vetinari]

That's what I expected, but detecting files in .ci_support should be cheap