aws-control-tower-customizations
aws-control-tower-customizations copied to clipboard
Build Project Should Fail When Template Does Not Exist
Describe the bug
The Build stage should fail fast when a non-existing template is referenced in manifest.yaml.
To Reproduce
- Add a new entry to
resourcesto themanifest.yamlfile. - Try to deploy it.
- It doesn't fail during validation when it cannot find the template, even though it does detect that the email doesn't exist:
...
193 | Manifest file validated against the schema successfully
194 | File templates/existing/template.yaml exists
195 | ERROR: File templates/non-existing/template.yaml does not exist
196 | ^^^ Caught an error: Setting exit status flag to 1 ^^^
197 | Changing path to template directory: /codebuild/output/src217356507/src/templates/
198 | Uploading template: existing/template.yaml to s3
...
Expected behavior The build job should fail fast. If the current behavior is by design, then it'd be nice to improve the logging. (See additional context.)
Please complete the following information about the solution:
- [x] Version: 2.5.2
- [x] Region: eu-central-1
- [x] Was the solution modified from the version published on this repository? No.
- [x] If the answer to the previous question was yes, are the changes available on GitHub? N/A
- [x] Have you checked your service quotas for the sevices this solution uses? N/A.
- [x] Were there any errors in the CloudWatch Logs? N/A
Additional context Interestingly, it fails at some other step without any helpful message:
...
391 | Failures count: 0
392 | Warnings count: 0
393 | Changing path to parameters directory: /codebuild/output/src217356507/src/parameters
394 | Exiting script with status: 1
395 | ERROR: One or more validation test(s) failed.
396 | Exit code: 1 returned from the validation script.
397 | ERROR: One or more validation test(s) failed.
As you can see the above logs are not really helpful. If you miss only one line (195) somewhere way above in logs, looking at this part of the logs confuses you that there's something is wrong with parameters which is not the case. Maybe would be nice to add a success message to checking parameters step to make it clear that this step is not the root cause of the failure.
Thanks for bringing this up @akefirad. I've gone ahead and made a backlog to discuss enabling faster failures when processing manifests that refer to missing resource/scp template files.
Sure. To be clear, I kinda like not failing fast. It’s just the logs that are not super helpful and might cause confusion.