-
Notifications
You must be signed in to change notification settings - Fork 37
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: support waves and add better if
control
#377
Conversation
…kflowProps.if` is applied
Co-authored-by: Kaizen Conroy <[email protected]>
This seems like an opinionated PR -- I'll review it when I have time, but it won't be this week. |
I appreciate it. I'm very much open to discussion on this. I was partially aiming at enabling functionality and syntax found in the codebuild pipeline without having to use the escape hatches. |
Hello @kaizencc, I'd like to utilize these features (more importantly the Wave support), and would like to provide as much support as possible moving forward with this PR. I'm open to discussion on how to move forward with this PR, and alter it as needed. It appears you may prefer to remove the Thank you! |
Superseded by #490 |
Fixes #376
Continuing the description there:
I've added
GitHubStage
which extendsStage
, adding the properties ofAddGitHubStageOptions
toStageProps
.Stage
ignores them, and they quickly get lost in the conversion to aStageDeployment
, so we also need to catch that conversion.I made a subclass of
Wave
calledGitHubWave
since n bothwave.addStage()
andpipeline.addStage()
(which is defined inpipeline_base
asthis.addWave(stage.stageName).addStage(stage, options)
) the theStage
object itself is tossed.GitHubWave
takes the parentGitHubWorkflow
as an additional parameter, andGitHubWorkflow.addWave()
callsnew GitHubWave(id, this, options)
.GitHubWave
only overridesaddStage()
to callparent.addingStageFromWave()
with the unalteredStage
in addition tosuper.addStage(stage, options)
.I have also added
GitHubWave.addStageWithGitHubOptions()
to matchGitHubWorkflow.addStageWithGitHubOptions()
as well asGitHubWorkflow.addGitHubWave()
, but those can likely go away.The trick is the JSII rules preventing "overriding or implementing a member using covariant parameter or return types" - which means we cannot make
addStage()
oraddWave()
take different parameters or have a different return type. However, we can accept and return classes that are descendants of those types, and useinstanceof
to catch them and get the additional information and functionality that they carry. So,pipeline.addStage()
can accept aGitHubStage
as aStage
, andpipeline.addWave()
can return aWave
that's actually aGitHubWave
. This allows us to maintain the same call structure but pass more information when we want.How well that works in the other languages is TBD. If the JSII rules are sufficient, then it should work. In the least, JSII compiles it. 😄