Skip to content
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

codebuild: merge "addBuildToPipeline" and "addTestToPipeline" APIs #1211

Closed
eladb opened this issue Nov 19, 2018 · 8 comments · Fixed by #1254
Closed

codebuild: merge "addBuildToPipeline" and "addTestToPipeline" APIs #1211

eladb opened this issue Nov 19, 2018 · 8 comments · Fixed by #1254
Assignees

Comments

@eladb
Copy link
Contributor

eladb commented Nov 19, 2018

Copy @skinny85

Let's consider normalizing this API together with the rest of the addToPipeline calls. I think we can just have an optional actionType property passed in, defaulting to build, and if someone wants to add the action as a test action, they can just set actionType to test.

@skinny85
Copy link
Contributor

ACK 👌🏻

@skinny85 skinny85 self-assigned this Nov 19, 2018
@skinny85
Copy link
Contributor

Scratch that 👌🏻. I just remembered why we did it the way we did.

We can't have one method for this, as addBuildToPipeline and addTestToPipeline return different Action classes. The 2 Action types have slightly different APIs. While a Build Action always has an output (and hence its outputArtifact field is defined as a non-optional type Artifact), the Test one does not (and so its outputArtifact field is of an optional type Artifact | undefined).

How do you want to proceed here @eladb ?

@eladb
Copy link
Contributor Author

eladb commented Nov 20, 2018

Is it really true that all build actions always have an output? Reference says 0-5.

@skinny85
Copy link
Contributor

In our model they do.

@eladb
Copy link
Contributor Author

eladb commented Nov 21, 2018

So maybe we should align to the service, and then we can make outputArtifact optional in both.

@skinny85
Copy link
Contributor

But there's a reason why we modeled it as not optional. It seems highly unlikely that someone would have a build that doesn't produce an output. Making it optional would also force customers to give the output a string name, which they don't care about in most cases, as it's only needed by the Pipeline itself. Also, you would be forced to say buildAction.outputArtifact!, as the type would have to be outputArtifact?: Artifact. Finally, making it optional would make our automatic Action input detection produce surprising results.

I don't think changing all of those behaviors to unify addBuildToPipeline and addTestToPipeline is worth it.

@eladb
Copy link
Contributor Author

eladb commented Nov 22, 2018

We usually try not to be opinionated about the service capabilities in L2. If the service allows users to define a build action without outputs, we should enable that too. But I guess that's a different discussion (raise issue? bring up with the team?)

Here's a proposal for this conversation: I believe the most common case is to use a CodeBuild project as a "build" step, correct? How about we rename addBuildToPipeline to addToPipeline and rename addTestToPipeline to addToPipelineAsTest?

@skinny85
Copy link
Contributor

Created issue: #1253.

Will submit a PR with the fix you mentioned @eladb.

skinny85 added a commit that referenced this issue Nov 28, 2018
… CodePipeline. (#1254)

BREAKING CHANGE: `addBuildToPipeline` was renamed to `addToPipeline` 
and `addTestToPipeline` was renamed to `addPipelineToTest` in order to align 
with naming conventions.

Fixes #1211
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants