Opt-in resources request mechanism

[jaimergp]

WIP. See #767 (comment)

Closes #752.

[aktech]

This PR adds the ability to request grant/revoke access to an Opt-in ci resource (cirun in this case).

This depends on conda-forge/conda-smithy#1703, which adds this functionality in the conda-smithy CLI, See this conda-forge/conda-smithy#1703 (comment)

Requesting or Revoking CI Resources Access

For specific CI resources that are available on an opt-in basis, you can request access by submitting a PR with your feedstock name added to a relevant file under the grant_access/ directory. If you wish to revoke access, please make changes in the revoke_access/ directory.

List of opt-in resources:

• GPU CI:
  • cirun-gpu-runner.txt: Grants access to the GPU runner on the main branch only.
  • cirun-gpu-runner-pr.txt: Provides GPU runner access for pull requests as well.

more of these will be added later, this is to get us started.

We're using txt files, for this via PR mechanism for the following reasons:

• consistency with other mechanisms like broken/not-broken, archive/un-archive
• dumb method for people to request/revoke access, with low possibility of errors/issues. We're eventually updating the .access.yml (to be created) file in the .cirun repo (example) eventually, this txt file method with concurrency one, also avoids creating conflicts in the .access.yml file.

[jaimergp]

I don't think we are offering admin-requests outside conda-forge so we could hardcode this, but this doesn't hurt either 👌

[jaimergp]

This is the configuration dictionary that maps {grant,revoke}_access/<name>.txt to an actual resource in ... .access_control.yml? Or where? Can you document the expected schema with a #: comment on top?

[isuruf]

@jaimergp, @aktech, this is good to go right?

(We need conda-forge/conda-smithy#1793 to clean this PR a little bit and conda-forge/conda-smithy#1794 to handle the teams correctly, but it should be possible to test without them)

[jaimergp]

this is good to go right?

I think so. There might be typos, mismatching identifiers, or simple errors that we will easily reveal once we try this live. The docs (as per comment above) seem to be outdated too, but I suggest we amend them once we know it's working.

One possible pain point is the maintenance of the access_control YAML here (for bookkeeping), because it might become a conflict source across PRs, so we need to ensure it's written in a consistent way (sort keys, etc). Again the kind of thing we will easily observe live.

[isuruf]

I ran this on a different branch and fixed a bunch of failures.
Need conda-forge/conda-smithy#1799 and conda-forge/conda-smithy#1796

[isuruf]

This is ready for a review now.

[beckermr]

LGTM!

[isuruf]

Thanks for the review. I'll start some docs PRs.

[jaimergp]

Awesome! Thanks! Please ping me in the docs PR when needed!