|
6 | 6 | - bench
|
7 | 7 | - scan
|
8 | 8 | - docs
|
9 |
| -- Maintain example **diagrams** for a better understanding of the architecture and sysdig secure resources |
10 |
| - - example diagram-as-code | https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/blob/master/examples/single-account/diagram-single.py |
11 |
| - - resulting diagram | https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/blob/master/examples/single-account/diagram-single.png |
| 9 | + - tests |
| 10 | +- Maintain example **diagrams** for a better understanding of the architecture and Sysdig secure resources |
| 11 | + - example diagram-as-code (check for `diagram.py` within the examples) |
| 12 | + - resulting diagram (check for `diagram.png` within the examples) |
12 | 13 | - Utilities
|
13 | 14 | - Useful Terraform development guides | https://www.terraform-best-practices.com
|
14 | 15 |
|
15 | 16 |
|
16 |
| - |
17 | 17 | # Pull Request
|
18 | 18 |
|
19 |
| -- Terraform **lint** and **validation is enforced vía pre-commit** | https://pre-commit.com |
20 |
| - - custom configuration | https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/blob/master/.pre-commit-config.yaml |
| 19 | +## 1. Check::Pre-Commit |
| 20 | + |
| 21 | +Technical validation for terraform **lint**, **validation**, and **documentation** |
| 22 | + |
| 23 | +We're using **pre-commit** | https://pre-commit.com |
| 24 | + - Defined in `/.pre-commit-config.yaml` |
| 25 | + - custom configuration | https://github.com/sysdiglabs/terraform-google-secure-for-cloud/blob/master/.pre-commit-config.yaml |
21 | 26 | - current `terraform-docs` requires developer to create `README.md` file, with the enclosure tags for docs to insert the automated content
|
22 | 27 | ```markdown
|
23 | 28 | <!-- BEGINNING OF PRE-COMMIT-TERRAFORM DOCS HOOK -->
|
24 | 29 | <!-- END OF PRE-COMMIT-TERRAFORM DOCS HOOK -->
|
25 | 30 | ```
|
26 |
| -- Kitchen tests | https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/tree/master/test/integration/kt_suite |
| 31 | + |
| 32 | +## 2. Check::Integration tests |
| 33 | + |
| 34 | +Final user validation. Checks that the snippets for the usage, stated in the official Sysdig Terraform Registry, are working correctly. |
| 35 | + |
| 36 | +Implemented vía **Terraform Kitchen** | https://newcontext-oss.github.io/kitchen-terraform |
| 37 | + |
| 38 | +- Defined in `/.github/workflows/ci-integration-test.yaml`. |
| 39 | + |
| 40 | +### Kitchen |
| 41 | + |
| 42 | +- Kitchen configuration can be found in `/.kitchen.yml` |
| 43 | +- Under `/test/fixtures` you can find the targets that will be tested. Please keep this as similar as possible to the Terraform Registry Modules examples. |
| 44 | + |
| 45 | +**Running Kitchen tests locally** |
| 46 | + |
| 47 | +Ruby 2.7 is required to launch the tests. |
| 48 | +Run `bundle install` to get kitchen-terraform bundle. |
| 49 | +GCP project and AWS credentials should be configured locally. |
| 50 | +```shell |
| 51 | +# launch the tests, in other words, it will run `terraform apply` |
| 52 | +$ bundle exec kitchen converge |
| 53 | + |
| 54 | +# will destroy test infrastructure, in short, it will run `terraform destroy` |
| 55 | +$ bundle exec kitchen destroy |
| 56 | + |
| 57 | +# run all the workflow. In first place, it will run an `apply`. Then, if and only if the `apply` works it will destroy the infrastructure. |
| 58 | +$ bundle exec kitchen tests |
| 59 | + |
| 60 | +``` |
| 61 | + |
| 62 | + |
| 63 | + |
| 64 | + |
| 65 | +### Terraform Backend |
| 66 | + |
| 67 | +Because CI/CD sometimes fail, we setup the Terraform state to be handled in backend (s3+dynamo) within the Sysdig AWS backend (sysdig-test-account). |
| 68 | +In order to be able to use this Terraform backend AWS credentials are configured as Github project secret |
| 69 | + |
| 70 | + |
| 71 | +### Deployed infrastructure resources |
| 72 | + |
| 73 | +Check project github secrets for clarification |
27 | 74 |
|
28 | 75 |
|
29 | 76 | # Release
|
|
32 | 79 | - Module official releases will be published at terraform registry
|
33 | 80 | - Just create a tag/release and it will be fetched by pre-configured webhook and published into.
|
34 | 81 | - For internal usage, TAGs can be used
|
35 |
| - - For officual verions, RELEASEs will be used, with its corresponding changelog description. |
| 82 | + - For official verions, RELEASEs will be used, with its corresponding changelog description. |
0 commit comments