fix: webhook expects REPOSITORY_ALLOW_LIST env var

[galargh]

Description

The ConfigResolver of the webhook lambda expects the env variable to be named REPOSITORY_ALLOW_LIST (see

terraform-aws-github-runner/lambdas/functions/webhook/src/ConfigResolver.ts

Line 18 in 1e40ecd

const repositoryAllowListEnv = process.env.REPOSITORY_ALLOW_LIST ?? '[]';

) whereas the one set by the webhook module was REPOSITORY_WHITE_LIST. I think it'd be great to follow up on #992, but it is beyond the scope of the fix proposed here now.

[npalm]

Thanks for creating the PR. This problem was noticed already in the PR #3830. As mentioned in that PR it is great to fix this.

But we are planning the depcreate this feture as well. The feature is from the early days of the module before runner groups were existing. Wondering what the use case is for this allow list.

[galargh]

Oh, I see. Sorry about that, I somehow missed this in a search. To be fair, I only noticed it when working on an unrelated feature (#3855) and quickly put up the fix PR.

I totally understand the plans to deprecate the feature altogether. One use case I did have was to enable a 2-step verification process of allowing new repositories to access the self-hosted runners. As in, it is not enough to allow webhook delivery to a new repository in the GitHub App, but you also have to explicitly modify the infrastructure (i.e. modify the allow list).

Thank you for the explanation and the link 🙇

[npalm]

Oh, I see. Sorry about that, I somehow missed this in a search. To be fair, I only noticed it when working on an unrelated feature (#3855) and quickly put up the fix PR.

I totally understand the plans to deprecate the feature altogether. One use case I did have was to enable a 2-step verification process of allowing new repositories to access the self-hosted runners. As in, it is not enough to allow webhook delivery to a new repository in the GitHub App, but you also have to explicitly modify the infrastructure (i.e. modify the allow list).

Thank you for the explanation and the link 🙇

Thanks for the feedback. In case we have the option to check the event is part of the group for which it is scaling the runners. Would that be good enough. Implementing this is not straighforward due to a lack of GitHub api's.