WIP: Add and configure CI for s3 full access policy module - issue 144

[mcgirr]

• Update the changelog
• Make sure that modules and files are documented. This can be done inside the module and files.
• Make sure that new modules directories contain a basic README.md file.
• Make sure that the module is added to tests/main.tf
• Make sure that the linting passes on CI.
• Make sure that there is an up to date example for your code:
  - For new modules this would entail example code for how to use the module or some explanation in the module readme.
  - For new examples please provide a README explaining how to run the example. It's also ideal to provide a basic makefile to use the example as well.
• Make sure that there is a manual CI trigger that can test the deployment.

Closes issue #144

[mcgirr]

We need to re-setup the AWS user for the tests it seems but apart from that this should be complete and ready for further review.

The other requirements listed out in issue #144 should be complete now:

• updating .gitlab-ci.yml
• define the stages, with linting being the first, and deploying stuff to aws second
• define a job in the aws stage that has a manual trigger - it does not run on its own when a new build is run on gitlab.. an operator would need to use the gitlab UI to trigger the job to run. I think this is when
• use credentials stored in gitlab secrets for now, we'll probably use vault in the future

[ketzacoatl]

This is looking great! We should figure out what we want this to look like as we scale out more tests/examples. I have a few comments in the PR to point those out.

[ketzacoatl]

I believe we should comment this so it's obvious to even the bash newb.

Also, this script is named tfbuild.sh but is specific to one example. When we run CI for this, are we running a bunch of examples, or only a specific example in each job?

[mcgirr]

I'm adding some comments now for this.

[mcgirr]

Also, this script is named tfbuild.sh but is specific to one example. When we run CI for this, are we running a bunch of examples, or only a specific example in each job?

We just have the one example at the moment. I think the best thing would be for me to change the build script name (as well as tftest.sh and tfclean.sh) to something specific to this example.

The other option is that when we do add other Haskell based tests for terraform-aws-foundation we would build them in this script as well.

The question we need answered is whether we want to manually run all the examples and their Haskell test code each time or allow the tests to be run on a per example basis.

If we're running tfbuild.sh (or similiar) in the Gitlab CI yaml with a manual action for just this example, it'd probably make more sense to rename it and keep it separate. This is if we had the aim of having different build scripts for the different examples and tests.

[mcgirr]

Right now the build step is using terraform to plan and apply the infrastructure needed for the test. So if something were to go wrong when we have more examples and tests, we'd need to address how to roll back all the infrastructure tfbuild.sh created.

[ketzacoatl]

We'll need to rebase this with some git trickery, resolving a few conflicts along the way, and we can then merge.

[mcgirr]

Closing this PR since it sounds like plan is to eventually shift all the CI for the repo to a Github Workflow (as part of changes like #320)