-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(codepipeline): final form of the CodeBuild Pipeline action #2716
feat(codepipeline): final form of the CodeBuild Pipeline action #2716
Conversation
I am failing to understand why we continuously make this API less ergonomic. This change goes against our design tenet to optimize for the common case. I’d argue that 99% of pipeline actions would have a single output. Can you please provide the motivation for this change? |
When given the choice between: interface {
things: string[];
} And: interface {
thing: string;
moreThings?: string[];
} I would also prefer the first one. Why would you purpose introduce that kind of shape irregularity on purpose? For one thing, the convenience argument assumes it will always be a human supplying the input values, and they will trivially be able to pick the right argument. At the same time, it makes it harder on any kind of automated or higher-level code, which for example might read the list of artifacts from a JSON file, or gets it from a service call (to name something)[1]. I made the same mistake with CompositePrincipal, and immediately a user complained because they had to jump through hoops to add a higher-level abstraction over it: #2327 Given that the cost is having to type an additional [1] Pre-emptive response to "you can just pick off the first element and pass it into another field": yes, but you're introducing more busywork and chance of error. In a different but related typical programming example, you can also return Yes, that means I will take |
it’s all about API ergonomics. If in 99% of the cases actions will have a single output, having to pass in an array is less comfortable. In some languages (ahm java) it’s even annoying. We should constantly think about the common case and optimize for it. If this was the only case, then okay, but I feel we have been continuously making our pipelines API less ergonomic (artifacts, etc) and I wanted to call out that this is not the right direction. The CDK is all about the developer experience. More verbosity and ceremony creates friction and redundant boilerplate for customers, and we should avoid them as much as possible. I am curious what is the motivation behind this change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've given it some thought and I am fine with this. I feel we will need to build some L3s for pipelines anyway, and we'll make all our ergonomics dreams come true at that layer.
BREAKING CHANGE: the output and extraOutputs properties of the CodeBuildAction were merged into one property, outputs.
658b1d0
to
31a347a
Compare
Rebased to solve conflicts. |
BREAKING CHANGE: the output and extraOutputs properties of the CodeBuildAction were merged into one property outputs.
Pull Request Checklist
design
folderBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.