✨ Restrict create-a-derived-table runners to specific branches / teams

[gwionap]

Describe the feature request.

We would like to ensure that create-a-derived-table workflows using specific self-hosted runners can:

• only be run on a branch which isn't main following a code owner review by a github team linked with that runner
• ideally only be triggered manually by a member of the code owner github team and only if pointing to main (i.e. won't trigger if a user implements a manual trigger via workflow dispatch on another branch)
• can run as normal / automated schedule once the workflow is in main, without further approvals

Describe the context.

As create-a-derived-table expands to allowing dbt projects to be created targeting other environments (i.e. other than AP) we won't to make sure that associated workflows have stronger security guardrails in place to ensure only the teams working directly with these external environments are able to trigger jobs against them.

Value / Purpose

The above will ensure only appropriate users of create-a-derived-table can develop workflows against external environments / require that relevant teams approve new workflows as they are created.

User Types

data engineers, create-a-derived-table users

[jhpyke]

Update with progress on ticket:

• Have implemented prod environment at github level, but this is still possible to overcome by a determined actor
• Created a PR looking to split the role for CADET into a dev and prod role. Dev role would be available to general runners, but prod role should be given to a runner group that can only target named workflow files @main.

[jhpyke]

Further Update:

Jacob W to update GHA runner image and chart to accept --runnergroup flag so we can create a runner group for CaDeT restricted workflows.