A CodeBuild buildspec installs runtime tools, compiles the code, then runs tests. The team finds that when the compile step fails, the test commands still run and produce confusing output, and they also want a small set of compiled files passed on as the build output. They want to express the ordered stages and the output files declaratively in the buildspec rather than scripting the control flow by hand. Which buildspec structure expresses this correctly?
- APut every command in a single build phase joined with shell and operators, and add a finally block that copies the output files, relying on the and chain to stop the tests when compilation fails.
- BUse the install, build, and post_build phases for the tool setup, compilation, and tests, set on-failure to ABORT on the build phase so a compile failure skips post_build, and declare the compiled files under the artifacts section as the build output. Correct
- CDefine the stages under a phases section but place the compiled output files in the cache section so they are retained, since the cache is the buildspec mechanism for passing files out of a build.
- DRun the install, build, and test commands as three separate CodeBuild projects chained in a pipeline, since a single buildspec cannot stop later commands when an earlier compile step fails.
Why A is wrong: Collapsing everything into one phase with manual and chaining is the hand-scripted control flow the team wants to avoid, and it makes the stages and outputs harder to read than the declarative phase structure.
Why B is correct: By default post_build still runs after a failed build phase, so setting on-failure to ABORT on the build phase makes a compile failure skip the post_build tests, while the artifacts section declaratively names the files to emit, matching the requested stages and outputs.
Why C is wrong: The cache section retains files for reuse by later builds, not for emitting outputs from the current build, so the compiled files would not be passed on as the build output as required.
Why D is wrong: Splitting into three projects is unnecessary overhead because one buildspec can halt on a failed phase with an on-failure setting, so this overcomplicates a requirement the phases structure handles natively.