test(modules): implement first tests of this repo

[leiicamundi]

Description

This pull request introduces testing for the modules, covering the following scenarios:

• Standard EKS values
• Upgrade of an EKS cluster
• Integration of EKS and RDS with custom values

The tests are organized into dedicated test suites and can be run in parallel using a separate copy of the module folder. By default, resources are cleaned up at the end of the tests.

Automation:

• A nightly cleanup of cloud resources is scheduled for 5 AM every day.
• Tests are triggered in the CI pipeline upon pull request approval and on-demand. Additionally, they run every Tuesday at 2 AM.

Please note that tests may take a considerable amount of time and may occasionally fail depending on available AWS resources.

Note: To initiate tests, the pull request must be labeled with "testing-allowed". Otherwise, tests will not be launched and will be marked as failed. Either "testing-allowed" or "testing-ci-not-necessary" labels must be added, the last one allows to skip tests.

Known Limitations

• Due to a maximum policy on Elastic IPs, tests cannot be run in parallel. (not for multiple workflows but works for a single workflow with multiple tests in //)
• IRSA integration is not included in this PR. Proper setup of ServiceAccounts, etc., would be required. If deemed relevant, we can add it in subsequent iterations.

Also implement https://github.com/camunda/team-infrastructure-experience/issues/160

[Langleu]

Due to a maximum policy on Elastic IPs, tests cannot be run in parallel.

What speaks against increasing the quota by a reasonable number? I did the same in eu-west-2 and eu-west-3

I was thinking about KMS a bit, how about just simply trying to schedule deletion for everything and accepting errors / ignoring errors || true. It will schedule deletion for the keys that are obsolete and has access to and the rest is simply ignored but ultimately ensuring that whatever the user created is removed.

[Langleu]

I'm still a bit confused on the whole labeling topic and whether we need it. Might make sense to sync on that topic in a quick call. E.g. trigger GHA by file changes --> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-pull_request-workflow-based-on-files-changed-in-a-pull-request Outside contributors would anyway need an approval.

[leiicamundi]

Thank you @maxdanilov and @Langleu for this initial review!

@maxdanilov, regarding the failing test, it's related to === NAME TestDefaultEKSTestSuite/TestDefaultEKS, failing due to user permission issues: operation error KMS: DescribeKey, HTTP response error StatusCode: 400, RequestID: cd1173f0-27cc-41b8-9cca-814517169a43, API error AccessDeniedException: User: arn:aws:iam::444804106854:user/tf-automation-user is not authorized to perform the kms:DescribeKey action on resource: arn:aws:kms:eu-central-1:444804106854:key/04ed5a73-118b-482c-a6b0-4eecb6971238 because no resource-based policy allows the kms:DescribeKey action.

This indeed is a permission issue that I'll need to address.

I agree that the error readability isn't optimal. I'll explore ways to improve it, perhaps by using a matrix similar to what crazymax has done.

---

I've taken your feedback and have consolidated all the tools via asdf and added some scripting via just, which indeed is more enjoyable. Let me know what you think. We could take it a step further with Renovate, which could parse certain versions listed in the justfile or in the GitHub action cloudnuke. We'll see how it goes.

---

Regarding the topic of labels, I do think a discussion will be necessary. @Langleu suggestion for a skip-ci seems to be what we're looking for, but unfortunately, we'd need the opposite of a skip: some kind of CI trigger. Maybe this could be directly achieved through a specific commit description, avoiding the use of a label altogether.

I'm aiming to ensure consistency in workflow triggering and to make sure that once the "test" or "terraform" label is applied by the labeler, tests aren't forgotten (either they pass or they're marked as unnecessary).

---

Regarding the Terraform topic, transitioning from Terraform to OpenTofu isn't difficult.

However, more and more companies aren't subscribing to the Terraform license, leading to fragmentation in the community and among our clients. What's the benefit of supporting Terraform over OpenTofu? If there's a global governance, I'm interested.

[leiicamundi]

Thanks for the review!

Here are some updates on what has been modified:

• Tests are now run in a matrix, simultaneously, accompanied by a test summary. Additionally, logs from the tests are filtered in the summary to provide a clear status. One can also choose not to trigger certain tests using the commit description message: skip-tests:TestName.
• The Tf binary is now configurable, with "tofu" set as the default. In the CI environment, it's set to "terraform".
• Added a license and made some enhancements to the README.
• Made KMS tests optional and disabled them in the CI due to permission issues with the "infex" user.
• Updated the labeler.

[leiicamundi]

Hello! Quick update from the last time:

• The renovate configuration now handles correctly .tool-versions and justfile
• The KMS test was failing due to the absence of pagination, this is now fixed
• The labels are not used anymore for triggering tests, instead we use paths: list in the workflow definition.

The latest CI tests are available at : https://github.com/camunda/camunda-tf-eks-module/actions/runs/8711829425 The changes are now ready to be reviewed! Thank in advance ;)

PS: the renovate config is redundant across repositories, this is something we could consolidate in an single repo.

[leiicamundi]

Thanks @maxdanilov and @Langleu for the final review, I've removed the autosort of .tool-versions and replaced it by a warning. The CI is running again and then it will be merged!