Out of curiosity, why does sst.Stack’s constructor require an sst.App instead of a construct? It’s a problem in the cdkPipeline because it gets called within the scope of a stage not an sst.App. I guess you’d have to implement an sst Stage type that implements the interface of sst.App to get around it? I guess that’s what the work in https://github.com/serverless-stack/serverless-stack/discussions/279 would involve?

The model we had in mind when first designing SST was that ppl would deploy an entire

App

to different environments/accounts. So we didn’t take

Stage

into consideration.

yeah to be fair, some of this stuff (like cross account deployment staging) are only available in CDK within the last 6-9 months or so

Yeah. I think we can change

sst.Stack

’s scope to take a

Construct

instead of limiting it to an

<http://sst.App|sst.App>

.

I think you’d maybe need to add in a stage as well? Basically you have

app->pipeline(app)->stage(pipeline)->stack(stage)

I haven’t thought this thru, but can you use cdk’s

Stage

construct?

I think so, everything seems to be ok until that last construct. For an idea of what we are trying to do check this repo out: https://github.com/aws-samples/cdk-pipelines-demo/tree/typescript. It has the following features which are super-cool: • self-updating pipeline so changes to the pipeline itself are automatically deployed and the whole thing restarted • the ability to block a stage on failing unit tests • the ability to roll back the pipeline if integration tests against a live stage fail • the ability to do a canary deploy of 10% of traffic to the new lambda version, 90% stay with the old for 10 minutes • any failure on the canary deploy (ie 5xx error) causes the pipeline to roll back • after 10 minutes of running cleanly with all tests green it deploys to pre-prod for QA and other to review • the prod stage is built and held until a manual step to approve deployment after QA reviews successfully To me, it’s the gold standard of what a CI/CD pipeline should be (including the github checks for linting and whatnot up front)

Yeah, that’s pretty neat! What’s missing to set it up? ie. say we changed Stack to take Construct in the constructor, does the following work?

<http://sst.App|sst.App> -> cdk.PipelineStack(app) -> cdk.Stage(pipeline) -> sst.Stack(stage)

I think so, I’d have to TIAS to know for sure

Yup.. let me make that change in the next release and let’s see from there

sounds good (no rush but any eta on that?)

I’ll aim for tmr

ok, no pressure - thanks!

Also, if you go into your

node_modules/@serverless-stack/resources/dist/Stack.d.ts

and change:

constructor(scope: App, id: string, props?: StackProps);

to

constructor(scope: cdk.Construct, id: string, props?: StackProps);

That should work for now.

weee!

Hey @Matthew Purdon I’m not totally following. Are you getting an error when child items call

root.logicalPrefixedName

? Can you share a code snippet maybe?

hey, sorry was getting dinner and chilling for a bit

Thanks @Matthew Purdon Lemme take a look at it

you bet, lemme know if you have questions we can jump on a call maybe

Sounds good! I’m in the middle of working on a new release. I will try out ur code as soon as i get the release out of the way!

I was considering that actually but I didn’t want to rely on the change if I was missing a more fundamental fix. I’ll give it a go, thanks for spending the time on it!

Yeah for sure! We definitely want SST to work well with CDK pipelines. As for this specific issue, it might be hard to test for. To add some context, before u can deploy a CDK app, u need to run

cdk bootstrap

once per region per account that you are going to deploy into. And it seems CDK pipeline wants all accounts (dev, prod, etc plus the account for the pipeline) bootstrapped before synthesizing. At least that’s what I’ve gathered so far. So the accounts have been bootstrapped once before, you technically shouldn’t get this error anymore.

so the change to cdk.json worked and I am past the build stage, now I am working on the self-update part which uses this buildspec:

{
  "version": "0.2",
  "phases": {
    "install": {
      "commands": "npm install -g aws-cdk"
    },
    "build": {
      "commands": [
        "cdk -a . deploy dev-MyBackendPipeline --require-approval=never --verbose"
      ]
    }
  }
}

Which fails because it can’t find the

dev-MyBackendPipeline

stack in the output from the previous stages. I am checking into it now

I've also been working on getting CDK Pipelines to place nice with SST. I've managed to get Pipeline deployed with a stage containing my App. The issue I'm running into now is when I try to develop locally my sst.Function doesn't trigger locally. It seems like the function doesn't stub because Pipeline doesn't deploy the stack until it reaches the stage its meant to deploy at.

Oh hmm.. I can see that

Wouldn't that destroy the Pipeline?

😅 lol I obviously didn’t think that through…

haha yeah I had the same though too. I'm working through some ideas on how we can get this to work too

Or maybe you can work in a separate stage?

we do this:

if (process.env.npm_lifecycle_event === 'start') {
    new ApplicationStack(app, 'api', { tags });
  } else {
    new PipelineStack(app, 'BackendPipeline', {
      description: 'The Pipeline that deploys the API',
      tags,
    });
  }

That seems like a good solution thanks