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

feat(pipelines): temporarily disable self-mutation #10466

Merged
merged 2 commits into from
Oct 19, 2020

Conversation

tomas-mazak
Copy link
Contributor

@tomas-mazak tomas-mazak commented Sep 21, 2020

The self-mutation feature of the CdkPipeline might at times get in the way of the pipeline development workflow. Each change to the pipeline must be pushed to git, otherwise, after the pipeline was updated using cdk deploy, it will automatically revert to the state found in git.

To make the development more convenient, the self-mutation feature can be turned off temporarily, by passing selfMutating: false property, example:

const pipeline = new CdkPipeline(this, 'Pipeline', {
  selfMutating: false,
  ...
});

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@rix0rrr
Copy link
Contributor

rix0rrr commented Sep 22, 2020

I see the use for disabling updatePipeline, but what's your use case for disabling dependent stacks?

We need that autoselect feature to deploy support stacks.

@tomas-mazak
Copy link
Contributor Author

tomas-mazak commented Sep 22, 2020

Yeah, that use-case for not updating dependent stacks might not be that strong, I've experienced an issue when I was working on the dependent stack (with no change to the pipeline stack itself), deploying from my laptop, but the pipeline always reverted the stack to the "git" version... I thought that being able to provide --exclusively param would be helpful then, but now thinking about it, simply disabling the UpdatePipeline stage would do as well.

Anyways, I still think the ability to disable self-mutation while developing would be really useful. If you agree with that but not happy with this approach, I am happy to implement it differently, for example by exposing a boolean flag, like disableSelfMutation or so. What do you think?

@rix0rrr
Copy link
Contributor

rix0rrr commented Sep 30, 2020

Let's do:

  /**
   * Whether the pipeline will update itself
   *
   * This needs to be set to `true` to allow the pipeline to reconfigure
   * itself when assets or stages are being added to it, and `true` is the
   * recommended setting.
   *
   * You can temporarily set this to `false` while you are iterating 
   * on the pipeline itself and prefer to deploy changes using `cdk deploy`.
   *
   * @default true
   */
  readonly selfMutating?: boolean;

Copy link
Contributor

@rix0rrr rix0rrr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provided feedback in a comment, need to hit "Request changes" to remove this from my TODO list :).

@tomas-mazak tomas-mazak force-pushed the cdkpipelines_custom_updatepipeline branch from e16ef03 to 262e013 Compare October 14, 2020 09:22
@gitpod-io
Copy link

gitpod-io bot commented Oct 14, 2020

@mergify mergify bot dismissed rix0rrr’s stale review October 14, 2020 09:22

Pull request has been modified.

@tomas-mazak
Copy link
Contributor Author

tomas-mazak commented Oct 14, 2020

@rix0rrr thanks for the feedback! I've update the PR in accordance with your suggestions, could you please have a look? I've updated the PR title and description too, for context, I am copying the old description below:


Currently, the UpdatePipeline stage is created inside the CdkPipeline class code and cannot be customized in any way. However, there are use cases where it might be useful to have more control over this stage, for example:

  • adding --exclusively argument to the cdk deploy command, to ensure dependent stacks are not updated by UpdatePipeline stage
  • making the UpdatePipeline stage no-op while developing the pipeline (otherwise every change needs to be pushed to git, as this stage updates the pipeline to the version found in git by default)

This PR exposes the updatePipelineAction in a similar way as sourceAction or synthAction are exposed.

Example:

const cdkPipeline = new CdkPipeline(this, 'CdkPipeline', {
  pipelineName: 'MyPipeline',
  cloudAssemblyArtifact,
  sourceAction: new codepipeline_actions.GitHubSourceAction(...),
  synthAction: SimpleSynthAction.standardNpmSynth(...),
  updatePipelineAction: new UpdatePipelineAction(nestedPipelineStack, 'UpdatePipeline', {
      cloudAssemblyInput: cloudAssemblyArtifact,
      pipelineStackName: pipelineStack.stackName,
      buildCommands: [`cdk -a . deploy ${pipelineStack.stackName} --require-approval=never --verbose --exclusively`],
  }),
});

@tomas-mazak tomas-mazak force-pushed the cdkpipelines_custom_updatepipeline branch from 262e013 to 549ad73 Compare October 14, 2020 09:37
@rix0rrr rix0rrr changed the title feat(pipelines): allow providing a custom updatePipelineAction feat(pipelines): temporarily disable self-mutation Oct 19, 2020
@mergify
Copy link
Contributor

mergify bot commented Oct 19, 2020

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 7387b52
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Oct 19, 2020

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit 8ffabb4 into aws:master Oct 19, 2020
@stephankaag
Copy link
Contributor

stephankaag commented Oct 26, 2020

@tomas-mazak @rix0rrr Is it expected behavior that selfMutating can not be re-enabled after being disabled?

When the SelfMutate stage is gone, the stage is not added when selfMutating is set to true again. This because the pipeline no longer updates itself :-)

Not sure if that is as intended?

@tomas-mazak
Copy link
Contributor Author

@tomas-mazak @rix0rrr Is it expected behavior that selfMutating can not be re-enabled after being disabled?

When the SelfMutate stage is gone, the stage is not added when selfMutating is set to true again. This because the pipeline no longer updates itself :-)

Not sure if that is as intended?

Not sure how it could work otherwise :) To re-enable, it, after setting it back to selfMutating: true, you need to update the pipeline from outside (typically using cdk deploy) and from then on, it will become self-mutating again. Bottom line is that you should only use that setting if you have a specific use-case for it (for me it is to be able to iterate faster over the pipeline when developing).

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 this pull request may close these issues.

None yet

4 participants