cirun integration isn't working well - handle in .cirun repo directly?

[h-vetinari]

We have

admin-requests/examples/example-open-gpu-server.yml

Line 1 in 07bcab9

action: cirun

but it's not working for simply adding resources (e.g. the next-bigger one) to already existing policies (e.g. no PR to https://github.com/conda-forge/.cirun after #1746). In case the bot runs precommit before opening a PR, it's also very likely that the integration cannot handle the new linting I was asked to add in conda-forge/.cirun#116.

The integration was also not working for other resources already present for .cirun up until very recently (c.f. #1744), meaning this process was never used for anything related to cirun-azure-windows-{2xlarge,4xlarge} or cirun-macos-m4-large.

Overall, I think this is a bad fit for admin-requests (it also contributes to policies split by resource, which is problematic for actual feedstock maintenance), and we should simply handle this in https://github.com/conda-forge/.cirun directly.

The one thing worth keeping IMO is

admin-requests/examples/example-open-gpu-server.yml

Lines 14 to 15 in 07bcab9

	# Send an automatic PR to the feedstock to enable cirun defaults
	send_pr: true

but I could imagine we could also trigger this from a reviewed and merged PR in https://github.com/conda-forge/.cirun if necessary.

[h-vetinari]

From #1819:

admin-requests/conda_forge_admin_requests/access_control.py

Lines 162 to 168 in fd804c9

	# this part is specific to github.com/Quansight/open-gpu-server
	if all(resource.startswith("cirun-openstack") for resource in resources):
	for key, value in DEFAULT_CIRUN_OPENSTACK_VALUES.items():
	for arg in value:
	register_ci_cmd.extend((f"--{key.replace('_', '-')}", arg))
	elif all(resource.startswith("cirun-") for resource in resources):
	pass

does not actually work for non-openstack runners. I had not understood this aspect at the time of da8b21e, apologies.

This is not easy to extend because the interface in smithy expects --cirun_users_from_json=... as an argument, which is not necessarily what we want for other resources (where a simple users: list should be created). We'll probably have to expand that interface (both in the yamls here, as well as in smithy; cirun itself should be generic enough AFAICT).

[h-vetinari]

OK, I think we have a qualitatively new problem: github will now give some BS "create your first GHA" dialogue when you click on the actions tab, and refuse to run any actions in PRs until you create some dummy workflow on main.

Once I did conda-forge/tinygrad-feedstock@6598f2c, suddenly CI in conda-forge/tinygrad-feedstock#11 & conda-forge/tinygrad-feedstock#12 started working, whereas before it refused to run.