fix(codebuild): start representing BuildSpec as object #2820
Conversation
Minimal representation of BuildSpec, formalizing some logic that was already in `Project` but not really well-placed there. It has very minimal support for merging buildspecs (only commands, not artifacts or anything else). Internal representation is hidden though, and can be improved and extended later.
| * | ||
| * Use this if you want to use a file different from 'buildspec.yml'` | ||
| */ | ||
| public static fromFilename(filename: string): BuildSpec { |
There was a problem hiding this comment.
fromBuildSource(filePath: string)
There was a problem hiding this comment.
I actually like fromFilename a lot more, fromBuildSource is a weird name in my opinion...
| // We have to pretty-print the buildspec, otherwise | ||
| // CodeBuild will not recognize it as an inline buildspec. | ||
| return Lazy.stringValue({ produce: (ctx: IResolveContext) => | ||
| Stack.of(ctx.scope).toJsonString(this.spec, 2) |
There was a problem hiding this comment.
why does this need to be lazy?
There was a problem hiding this comment.
Because we need access to stack.toJsonString.
CloudFormationLang.toJson() would have been good enough, but that's internal and hidden so I can't get to it.
There was a problem hiding this comment.
Some minor comments, but in general looks good to me.
I wonder whether we could go a tiny step further, and provide another class with an API like:
BuildSpec.version02({
preBuild: ['npm run install'],
build: ['npm run build'],
postBuild: ...
artifacts: {
baseDirectory: 'foo',
files: ['**/*'],
},
secondaryArtifacts: {
bar: {
// ...
},
},
});But I understand if you consider that to be "too big" for this PR.
| * | ||
| * Use this if you want to use a file different from 'buildspec.yml'` | ||
| */ | ||
| public static fromFilename(filename: string): BuildSpec { |
There was a problem hiding this comment.
I actually like fromFilename a lot more, fromBuildSource is a weird name in my opinion...
| /** | ||
| * BuildSpec that understands about structure | ||
| */ | ||
| class StructuredBuildSpec extends BuildSpec { |
There was a problem hiding this comment.
This name is surprising to me... I would actually say this is the complete opposite of a StructuredBuildSpec - it's an UnstructuredBuildSpec, because I can say new StructuredBuildSpec({ foo: 123 }), and nothing would complain (until deployment, that is...).
If UnstructuredBuildSpec is too weird, maybe ObjectBuildSpec?
| @@ -20,8 +20,9 @@ export class CloudFormationLang { | |||
| * in CloudFormation will fail. | |||
| * | |||
| * @param obj The object to stringify | |||
| * @param number Indentation to use | |||
There was a problem hiding this comment.
I think you meant @param space here...? Also, what's the default?
| return { | ||
| ...sourceJson, | ||
| buildSpec: JSON.stringify(buildSpec, undefined, 2) | ||
| buildSpec: buildSpec.toBuildSpec() | ||
| }; | ||
| } else if (this.source.type === SourceType.None) { | ||
| throw new Error("If the Project's source is NoSource, you need to provide a buildSpec"); |
There was a problem hiding this comment.
There is an interesting edge case here. I think the actual behavior should be to error out also if no source has been provided, and the build spec has been given as BuildSpec.fromFileName(). I'm not sure what would be a good way to accomplish that - perhaps a public abstract validate(source: BuildSource): string[] method on the BuildSpec class?
It's not super crucial though.
Minimal representation of BuildSpec, formalizing some logic that was already in `Project` but not really well-placed there. It has very minimal support for merging buildspecs (only commands, not artifacts or anything else). Internal representation is hidden though, and can be improved and extended later. BREAKING CHANGE: * **codebuild**: buildSpec argument is now a `BuildSpec` object.
Minimal representation of BuildSpec, formalizing some logic
that was already in
Projectbut not really well-placed there.It has very minimal support for merging buildspecs (only commands,
not artifacts or anything else).
Internal representation is hidden though, and can be improved and
extended later.
Pull Request Checklist
designfolderBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.