improve CI

[scottyhq]

the CI workflows have some hardcoded values and don't do much that is sophisticated. Some ideas for improvement

1. helm lint or helm upgrade --dry-run in PRs to ensure yaml configuration is correct. ideally the PR would actually get deployed someplace like a staging environment for testing, but that's much more complicated to implement, so will leave for another day.

2. terraform has some options to post summaries directly in PR comments https://github.com/marketplace/actions/hashicorp-setup-terraform#usage

3. once initially setup, it would be good to enforce branch protection so that changes have to happen via PRs and can only be merged if PR tests pass.

[lsetiawan]

I think the Helm.yml can be improved by having a pre-job that pull out the outputs from terraform for the values like cluster_name, region, etc. Since the helm depends on the infrastructure being there already anyways.

[scottyhq]

Agreed. tfvars files are very simple, so it would be nice if that were the only thing needed to edit.
https://www.terraform.io/docs/language/values/variables.html#variable-definitions-tfvars-files

Alternatively, it might actually be simpler to just use a generic name for the cluster, namespace, and helm release like 'hackweek-jhub' and if needed set the environment variable AWS_DEFAULT_REGION for actions

[lsetiawan]

With terragrunt we can just modify everything within common.yml and pull values from there maybe. Also, could I create a whole test hackweek infrastructure for this on the pangeo-access account? I realized that the terraform CI actually perform an apply to AWS, so I cancelled it for now ... We'd have to do a plan and apply using terragrunt so that everything spins up all at once :)

[scottyhq]

With terragrunt we can just modify everything within common.yml and pull values from there maybe.

Also, could I create a whole test hackweek infrastructure for this on the pangeo-access account? I realized that the terraform CI actually perform an apply to AWS

yes feel free to apply and destroy at will!

If you need to bypass CI, I've been using the following setup
(~/.aws/credentials)

[github]
aws_access_key_id=XXXXXXXXXXXXXX
aws_secret_access_key=XXXXXXXXXXXXXXXX

(~/.aws/config)

[profile github-eks]
role_arn = arn:aws:iam::XXXXXXXXXX:role/github-actions-role
source_profile = github

Anyone with access to the S3 backend currently (so I think anyone in the aws account 'admin' group) can obtain the github user access keys with terraform state pull | jq '.resources[] | select(.type == "aws_iam_access_key") | .instances[0].attributes' ...(or create a second set of keys)

I find copying and pasting credentials as environment variables from aws sts assume-role very tedious (but probably best from a security standpoint https://blog.gruntwork.io/a-comprehensive-guide-to-managing-secrets-in-your-terraform-code-1d586955ace1)