Provide CI to verify Terraform changes

[tomkerkhove]

Provide CI to verify Terraform changes are still semantically valid, ie by doing a terraform plan.

Example per docs:

[JorTurFer]

Maybe we can't follow this flow exactly because for init and plan we need the secrets and PRs from forks can't access to them.
Let's discuss if repo will be public or not and based on that, I'll update the CI

[tomkerkhove]

I'm not sure if that problem is a problem when doing #2

[JorTurFer]

I'm not sure if that problem is a problem when doing #2

it is, because GH doesn't have non-secret variables, I mean, if we want to avoid having to hardcode any value (like clientId for instance), we need to use secrets, it's the only way.
We have the same issue with OIDC permission inside GITHUB_TOKEN, depending on if the PR comes from a fork or not, the maximum access is different, read is the max access from forks

I know, GH is really particular...

[JorTurFer]

To clarify, I'm not saying that we can't do anything, but maybe our CI checks are quite different

[tomkerkhove]

But isn't read all that we need?

it is, because GH doesn't have non-secret variables, I mean, if we want to avoid having to hardcode any value (like clientId for instance), we need to use secrets, it's the only way.

I don't see much of a problem here to be honest. A client ID is an ID and not a secret.

[JorTurFer]

it's an example, but we wil have the same situation with AWS and GCP, and also with the GH_PAT to write secrets in the other repo.
I need to think better in how to test this. maybe with atlantis bot having the secrets in our ARM machine or similar

[JorTurFer]

I have done this https://github.com/kedacore/testing-infrastructure/blob/main/.github/workflows/pr-validation.yaml