terraform-google-modules
ci: refine PR tests to exclude unchanged complex examples
TL;DR
Identified in 773, debugged in https://github.com/terraform-google-modules/terraform-docs-samples/pull/777
After changes in https://github.com/terraform-google-modules/terraform-docs-samples/pull/669, there are still samples that aren't pruned. This increases the CI execution time
Expected behavior
No response
Observed behavior
No response
Terraform Configuration
build/int.cloudbuild.yaml
Terraform Version
cloud-foundation-toolkit latest
Additional information
No response
Example remaining folders:
looker/ et al contains test.yaml files, so samples are validated but not executed (slight increase to CI exec time) functions/ contains reference code (.js, package.json), so samples are executed completely (and failing in 777 exec)
@apeabody confirming your intent on 669, this comment was added to the code:
Remove leaf folders without changes or non-tf resources
Do you intend to always test samples with test.yaml files? Always samples with other artifacts?
@apeabody confirming your intent on 669, this comment was added to the code:
Remove leaf folders without changes or non-tf resources
Do you intend to always test samples with
test.yamlfiles? Always samples with other artifacts?
Hey @glasnt! I'd have to refresh my memory, but the intention was to avoid deleting non-TF test artifacts that are (commonly) in sub-directories below the TF code itself. Likely the logic can/should be improved. :) At the very least it should be safe to delete folders with test.yaml as those are not per say test artifacts.
There may be a new general solution on this coming from my team, but in the mean time, I will address some of the more flaky resource-heavy tests as to try and streamline the process for other PRs
There may be a new general solution on this coming from my team, but in the mean time, I will address some of the more flaky resource-heavy tests as to try and streamline the process for other PRs
As a quick fix, I was thinking we could first run the original logic to purge root level directories with zero changes, and then depend on the new logic just to clean the remaining directories further. Likely still some edge cases, but that would give us at least the best of both right in the meantime.