When using cirun.io in an organization, quite often you need the ability to control access to runners per repository to control usage, cost and availability. Cirun provides a way to access control runners via the following mechanism:

You'd create a repository named `.cirun` in your organization and create a couple of config files to control access.

1. `.cirun.global.yml`: This is the file where you'd define all the runner configurations you'd want to use in the organization. The format of this file is same as `.cirun.yml`, for example:

runners:
  - name: gpu-runner
    cloud: openstack
    instance_type: gpu_large
    machine_image: ubuntu-2204-nvidia-docker-20221229
    region: RegionOne
    labels:
      - cirun-openstack-gpu
      - openstack-gpu-runner

  - name: cpu-runner
    cloud: openstack
    instance_type: ci_medium
    machine_image: ubuntu-2204-cloud-jammy-20221104
    region: RegionOne
    labels:
      - cirun-cpu-runner
      - openstack-cpu-runner

  - name: aws-runner
    cloud: aws
    instance_type: t2.medium
    machine_image: ami-06fd8a495a537da8b
    preemptible: true
    labels:
      - cirun-runner

2. `.access.yml`: This is the file, where you'd define the rules for access control. Let's take an example to understand how it works:

version: 1

policies:
  - id: cirun-sandbox-policy
    repo: cirun-sandbox
    teams:
      - core
      - alpha
      - beta
  - id: cirun-demo-repo-policy
    repo: cirun-demo
    teams:
      - core
      - demo

access_control:
  - resource: gpu-runner
    policies:
      - cirun-demo-repo-policy
  - resource: cpu-runner
    policies:
      - cirun-sandbox-policy
      - cirun-demo-repo-policy
  - resource: aws-runner
    policies:
      - cirun-demo-repo-policy
      - cirun-sandbox-policy

Let's try to understand this configuration:

- `policies`: A policy is a set of a repository and teams.
- `access_control`: Access control defines which policies have access to resource.

To simplify which combination of repository and teams have access to a resource. In other words, if there is an event of a workflow job and that requires cirun to spinup a resource (runner), it will only spinup a runner if that workflow job was triggered by a member of the given team on a given repository in a policy defined on that resource.

### From the above example:
If a workflow job is triggered on `aktechlabs/cirun-demo` and it requests the resource `gpu-runner`, then it must have been triggered by a member of `demo` or `core` teams to be authorized get a `gpu-runner`.

## Conda forge: Admin Requests Access control process

- repository
- teams
- resource
- policy for branch (?)

## `grant_access/cirun-gpu-runner-pr.txt`

foo-feedstock

resulting policy:

  - id: foo-feedstock-policy
    repo: foo-feedstock
    teams:
      - foo-feedstock
    pull_request: false

To cater for the case lets say some feedstock merge
in various branches for various versions example python.

- admin_requests/.access_control.yml - will be updated in CI after success for access control request