Already deployed codepipeline/codebuild won't update on configuration changes

[s1mrankaur]

trafficstars

Describe the bug

When there are changes made to the Buildspec without changing the action and then I run cdk synth stackname and cdk deploy stackame, it does not seem to deploy the configuration change.

Happens when I try to change build configuration like timeout as well. Doesn't seem to be reflected in the pipeline that is already deployed.

Expected Behavior

Expected deployed pipeline to be cancelled and the specific stage with changed codebuild config to have the new configuration changes

Current Behavior

No changes are reflected

Reproduction Steps

using the pipeline from https://github.com/awslabs/aws-simple-cicd/

In tests-project.ts, add

    buildSpec: codebuild.BuildSpec.fromObject({
        batch: {
          'fast-fail': false,
          'build-list': [
            {
              'identifier': 'build1'
            },
            {
              'identifier': 'build2'
            },
            {
              'identifier': 'build3'
            },
            {
              'identifier': 'build4'
            },
            {
              'identifier': 'build5'
            }
          ]
        },

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.35.0 (build 5c23578)

Framework Version

No response

Node.js Version

14.18.3

OS

Windows

Language

Typescript

Language Version

No response

Other information

No response

[gshpychka]

Are you sure you waited until the self-mutation step completed?

[s1mrankaur]

@gshpychka Yes

[s1mrankaur]

I ended up having to delete local cdk.out folder , running cdk synth and cdk deploy commands again but would still like to know why that was the case

[gshpychka]

Oh, my bad, I assumed you were using CDK pipelines. It doesn't look like that project has any self-mutation, does it? If not, you have to do a cdk deploy to change the pipeline, this is expected.

[s1mrankaur]

Yes, I did cdk synth and cdk deploy multiple times but the pipeline did not update , until I deleted the local cdk.out folder and repeated the synth and deploy

[gshpychka]

Can you reproduce the error?

[rix0rrr]

Thanks for jumping in @gshpychka!

This is exactly why CDK Pipelines has a self-mutation step: changes to the pipeline need to be deployed by some CloudFormation deployment, either cdk deploy or something inside the pipeline itself.

cdk deploy should have worked, and caching should not come into it. It's a little weird that you needed to clean cdk.out. Please report that as a separate bug with as much detail as you can if it happens again.

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

[s1mrankaur]

Just wanted to update here that this issue continues to happen from time to time.

[Pipo93]

I'm also facing the same issue in one of our projects. When there are only changes to the buildSpec a cdk deploy doesn't have any effect on the pipeline, it only changes the CloudFormation template.

@rix0rrr Here's an example which doesn't update the Pipeline, e.g. when I remove the node --version command inside buildSpec:

import { Stack, type StackProps } from "aws-cdk-lib";
import type { Construct } from "constructs";
import { BuildSpec, LinuxBuildImage, Project } from "aws-cdk-lib/aws-codebuild";
import { Artifact, Pipeline } from "aws-cdk-lib/aws-codepipeline";
import {
  CodeBuildAction,
  CodeStarConnectionsSourceAction,
} from "aws-cdk-lib/aws-codepipeline-actions";

export class ExampleStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);

    const codeBuildProject = new Project(this, "Project", {
      environment: {
        buildImage: LinuxBuildImage.STANDARD_7_0,
        environmentVariables: {},
      },
      buildSpec: BuildSpec.fromObject({
        version: "0.2",
        phases: {
          install: {
            "runtime-versions": {
              nodejs: "20.10.0",
            },
          },
          build: {
            commands: [
              "ls -la",
              "node --version",
            ],
          },
        },
      }),
    });

    const sourceCode = new Artifact("SourceCode");
    const buildOutput = new Artifact("BuildOutput");

    new Pipeline(this, "Pipeline", {
      restartExecutionOnUpdate: true,
      crossAccountKeys: false,
      stages: [
        {
          stageName: "Source",
          actions: [
            new CodeStarConnectionsSourceAction({
              actionName: "Source",
              owner: "<OWNER>",
              repo: "<REPO>",
              branch: "main",
              output: sourceCode,
              connectionArn:
                "<CODESTAR_CONNECTION_ARN>",
              triggerOnPush: false,
            }),
          ],
        },
        {
          stageName: "Build",
          actions: [
            new CodeBuildAction({
              actionName: "Build",
              input: sourceCode,
              outputs: [buildOutput],
              project: codeBuildProject,
            }),
          ],
        },
      ],
    });
  }
}

[pahud]

Hi @Pipo93

We won't track closed issues like this. Could you help us create a new issue and link back to this one? Thanks.

[Pipo93]

@pahud I did some more research and it might actually work as intended, but I'm not 100% sure. When starting the pipeline manually via the CLI command, it indeed uses the updated project. So what actually happens is, that the deploy works as expected, it just doesn't trigger the pipeline execution as it does on the first deploy.

My initial assumption was that it gets triggered whenever an update to the pipeline happens. I can't rely on automatic triggers on push in my use case this is why I was trying to solve it via the deploy.

If this isn't the expected behavior, for sure I'm happy to create a new issue :)