feat(pipelines): add synthCodeBuildDefaults

[hoegertn]

This change allows specifying the codeBuildDefaults for the synth-action as it is already possible with assets and self-mutation.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[hoegertn]

/cc @rix0rrr

[rix0rrr]

The reason it's possible for those other actions is because you have NO CHOICE other than to specify them there, as you don't control any other aspects of their creation. For the synth step that's not true, if you care you can always drop to a CodeBuildStep and specify what you need there. The same question is going to arise for arbitrary ScriptSteps in pre and post positions, and we're also not going to add codeBuildDefaults for those.

I'm trying to keep the API narrow yet complete--do you have an example of a use case that would be markedly improved by supplying the properties here instead of somewhere else?

[hoegertn]

I am trying to keep the separation of Blueprint and Implementation. So I can provide the ShellStep to synthesize and have the CodeBuild overrides somewhere else. E.g. in a construct library, I want to set env, VPC, etc but let the user provide the ShellStep for the synthesize action.

[rix0rrr]

If that's the goal, then you can still have them specify ShellStep and turn it into a CodeBuildStep in your construct library.

And VPC would probably apply to all codeBuild steps and hence would go into codeBuildDefaults.

Do you have an actual immediate issue, or is this hedging against the future?

[hoegertn]

It is an immediate issue as I want to set a buildEnvVariable for synth and setting it for all build projects fails for asset actions (#15628)

But I can workaround it if you do not want this to be included in the API

[rix0rrr]

I do see the point (and--confession time--I did have it in originally), but I'd prefer to keep the API minimalist for now and not have too many ways to achieve the same goals. If you could supply both synthCodeBuildDefaults as well as use a CodeBuildStep, then which one is the "right" solution? I'd prefer to avoid the confusion.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 83f2493
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).