allow for optional use of github cloud runner

[kewalaka]

I was hoping to be able to be able to optionally use cloud hosted runners using a var.

The use case is when doing E2E tests outside of Microsoft, whilst wanting to align to the policies in grept.

I would prefer to avoid the 'skipping steps' approach, thought I could just put some conditional logic in the shell script, but I can't see a way to make workload federated id function from az cli, except via a GitHub action or some bashing & curling that looks even worse than this 😅

thoughts?

[matt-FFFFFF]

Hi @kewalaka

Unfortunately we cannot make this optional for AVM, however you could still use this template repo and a custom set of grept rules!

We use grept to rewrite certain aspects of these files.

Check out the files here: https://github.com/Azure/Azure-Verified-Modules-Grept

[matt-FFFFFF]

See here:

https://github.com/Azure/Azure-Verified-Modules-Grept/blob/main/terraform/rendered_support_md.grept.hcl

[kewalaka]

hi @matt-FFFFFF - the PR includes an approach to keep the status quo but allow the use of cloud runners via an optional repo var.

that way grept can still do its thing & set the required way, and those of us wanting to avoid having to self host runners can use the GH ones by setting a repo-scoped variable.

I'm not sure you've seen this PR contents - or maybe the issue is having any bolt hole at all (or frankly, the ugliness of the proposed solution 😂) - but raising just in case!

thanks

[kewalaka]

btw - its not so much that there isn't customisation for people "insourcing" AVM - it's just that when directly contributing into MS I'd be flipping this setting between running in the cloud vs running in MS. I like to run the E2E tests before i raise a PR :)

or maybe i should just get less lazy and spin up some self hosted runners too!

[matt-FFFFFF]

Hi,

I get the approach. The issue is that module authors are admins of their repos and can then elect whether to use self hosted or cloud based. This isn't compatible with the governance approach.

However your point about working from a fork is valid. I wonder if we can base the expression on the repo organization.

[matt-FFFFFF]

Following on, we will provide a method of running the tests locally. This will unblock working from a fork.

You can do this now by invoking make from within the container.

[matt-FFFFFF]

Unfortunately we cannot merge this so closing