cdk.pipelines - Allow the configuration of Caching properties for Synth CodebuildProject

It would be helpful to add the abillity to set caching for the synth code build project in a pipeline. This will help with speed up the build and run times of pipelines. I have achived the desired result by using escape hatches but this is not particaully elegent and could be improved with some minor work.

if 'SynthProjectCachePropertys' in synth_cfg.keys():

            # the pipeline needs to be built bfore you can extract the synth
            # codebuild project. 
            # Everything needs to be done with buildingpipeline prior to this, 
            # as you can't modify it after you build. s
            pipeline.build_pipeline()

            codebuild_cache_bucket = s3.Bucket(self, 'codebuild_cache_bucket',
                auto_delete_objects= True,
                removal_policy= cdk.RemovalPolicy.DESTROY,
                block_public_access= s3.BlockPublicAccess.BLOCK_ALL
            )

            # finally use an escape hatch to manipulate the codebuild
            SynthCodeBuildProject: codebuild.CfnProject = pipeline.synth_project.node.default_child
            SynthCodeBuildProject.ProjectCacheProperty(
                type="S3",
                location = codebuild_cache_bucket.bucket_name,
                modes = synth_cfg['SynthProjectCachePropertys']['modes'],
            )
            # allow the code build project permission.
            codebuild_cache_bucket.grant_read_write(SynthCodeBuildProject)

### Use Case

Speed up the pipeline time. 

[bilalq]

FWIW, the “this code creates mostly what I need except this one property…” problem crops up a lot more in CDK. I don’t think the solution should be “let’s just keep adding properties everywhere”. Although I don’t have the full solution yet either…

While that’s true, the problem is exacerbated by the lack of access to encapsulated resources. Just being able to get a reference to the underlying project would allow users to make tweaks without needing to keep expanding the API of higher level constructs.

Between expanding the API to cover caching use-cases and exposing the underlying project that is encapsulated, which would you prefer @rix0rrr?

I’ve run into at least half a dozen issues when trying to setup CI/CD pipelines using CodeStar/CodeBuild/CodeArtifacts/CodePipeline. Some problems can be worked around by using CFN escape hatches, but others encapsulate so much that it’s hard to get at things and I end up re-implementing constructs entirely.

[mrpackethead]

FWIW, the “this code creates mostly what I need except this one property…” problem

Yes, murphy’s law is that its always that one property that is’tn there. 😃 I agree with you, that adding more propertys is not really a scalable solution to the general problem… If your contruct starts specifiying ‘propertys’ of a an underlying reoource the construct, ( rather than the resource itself ), then it woudl always be desirable that there is an ‘easy’ way to acces that resource… if this coudl be done as a ‘general’ thing. ( thats a big ask i know ) then all the ‘mostly want i need’ problems go away.