Aws-cdk: [cdk-pipelines] unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope .

Created on 11 Aug 2020  路  18Comments  路  Source: aws/aws-cdk

When attempting to implement the cdk pipeline example found in this blog post, several of us have gotten the error _unable to determine cloud assembly output directory. Assets must be defined indirectly within a "Stage" or an "App" scope ._ once the addApplicationStage step is added to the code.

import { CdkpipelinesDemoStage } from './cdkpipelines-demo-stage';

// ...

// This is where we add the application stages
pipeline.addApplicationStage(new CdkpipelinesDemoStage(this, 'PreProd', {
  env: { account: 'ACCOUNT1', region: 'us-east-2' }
}));

The Question

What is the meaning of this error ? It isn't clear at all what one should do to solve it.

Environment

  • CDK CLI Version: 1.57

  • Language: TypeScript

@aws-cdpipelines guidance needs-triage

Most helpful comment

Based on experimentation, we determined this error is due to their being a subtle difference in the list of cdk packages in the package json. Specifically we had _aws-cdk/core_ set to "1.57.0" whereas the other aws-cdk pacakges being used were set to version "^1.57.0". Correcting this mismatch, deleting the node_modules and the package.lock.json, and performing a new npm install fixed the issue. I would say though that the error message here isn't all that helpful, and may be misleading.

All 18 comments

@SomayaB why did you label this as a "bug" ?

@billmcknight1953 I can't tell without a reproducing sample.

Based on experimentation, we determined this error is due to their being a subtle difference in the list of cdk packages in the package json. Specifically we had _aws-cdk/core_ set to "1.57.0" whereas the other aws-cdk pacakges being used were set to version "^1.57.0". Correcting this mismatch, deleting the node_modules and the package.lock.json, and performing a new npm install fixed the issue. I would say though that the error message here isn't all that helpful, and may be misleading.

I can confirm that @billmcknight1953 . I had a dependency mess on one project, yarn and npm were used together

Seems like this is still an issue. In the course of a simple project, CDK went from 1.59.0 to 1.60.0 to 1.61.1 and at each transition i got into major issues of first - errors in the typescript files because of parameter type mismatch - had to update/reinstall all of the packages... but then, got into the error above... so applying @billmcknight1953's fix did it, but i had to reinstall every single package and dependency... all because of an upgrade to CDK?!

Am i missing something here? there's gotta be a way to keep things within a minor release so they don't completely break your builds...

I was getting the "unable to determine cloud assembly output directory" message. I followed the suggestion to delete node modules and update everything to the latest cdk (1.61.1). Then I started getting message about not having credentials to access the Environment (Account-Region). I was trying to use a sso profile which I initialized and tested using "aws sso login...". Then I changed to using the default profile. No time to investigate why it did not work with sso, but the bootstrap works fine now with this default profile.

Im still getting this error with 1.61.1

me too;
To fix...
corrected a couple of packages from 1.61.0 to 1.61.1 but that didn't fix the issue;
removed the package-lock.json;
removed node_modules recursively and forcefully;
reinstall node packages;
then, I changed command from "cdk deploy" to "cdk deploy CdkpipelinesDemoPipelineStack";
and, it worked!

me too;
To fix...
corrected a couple of packages from 1.61.0 to 1.61.1 but that didn't fix the issue;
removed the package-lock.json;
removed node_modules recursively and forcefully;
reinstall node packages;
then, I changed command from "cdk deploy" to "cdk deploy CdkpipelinesDemoPipelineStack";
and, it worked!

The above worked for me. Running cdk deploy directly worked.
This is running 1.62.0 after upgrading from 1.61.1
Every update I now nuke the package lock and modules folder.

Still happening upgrading from 1.62.0 to 1.63.0. As suggested, deleting node_modules and package.lock.json resolved it.

As for closing this ticket - all versions were matching prior to my deleting the file/folder and this project was created 'cleanly' starting with 1.62.0, so I'd consider this to still be a bug and suggest you reopen the issue.

I just did 1.62.0 to 1.63.0 before updating I removed the cdk.out folder and the lock file.
I did not delete the module files.
It seemed to work with that method.

This worked for me (on my local machine):

  1. Delete node_modules and package-lock.json (alternatively I'd think npm ci would do the same)
  2. npm i
  3. cdk synth to verify. This yielded an actual error in my 位 definition. Since I'd shuffled directories around for tidiness, I'd neglected to adjust the path to my 位 code (an error which didn't surface before steps 1 & 2)
  4. Fixed the error, commit and push

Pipeline "build" step (synth) happy again!

That's because of this line in stage.ts :

  public static of(construct: IConstruct): Stage | undefined {
    return Node.of(construct).scopes.reverse().slice(1).find(Stage.isStage);
  }

  /**
   * Test whether the given construct is a stage.
   *
   * @experimental
   */
  public static isStage(x: any ): x is Stage {
    return x !== null && x instanceof Stage;
  }

It happened for me when I had @aws-cdk/core specified version 1.68.0 and @aws-cdk/eks version at ^1.68.0.

Then npm resolved the @aws-sdk/core for @aws-cdk/eks to version 1.69.0, downloaded the specific 1.69.0 version into eks's node_modules (instead of doing nothing and letting node go up one level to find the core module).

This made the Stage prototype object different in core and eks modules, hence making the referenced code not work.

A possible solution (but less secure) would be to use the typeof operator instead of instanceof in the Stage.isStage(x) function. The fact that it is less secure should be kind of ok, since anyway cdk runs a lot of untrusted code.

By the way, the "solution" was for me to substitute 1.68.0 to ^1.68.0 in my package.json file, delete the node_modules directory, run npm install and check that the node_modules directory structure was OK.

Getting the same error with my dependencies:

"devDependencies": {
    "@aws-cdk/assert": "^1.68.0",
    "aws-cdk": "^1.68.0",
  },
  "dependencies": {
    "@aws-cdk/aws-waf": "^1.68.0",
    "@aws-cdk/core": "^1.68.0",
    "@aws-solutions-constructs/aws-cloudfront-s3": "^1.68.0",
  }

Steps:

  • Removing node_modules
  • Removing package-lock.json
  • running npm install

Then looking at the package-lock.json I see it's install 1.69.0 somehow:

"dependencies": {
    "@aws-cdk/assert": {
      "version": "1.69.0",
      "resolved": "https://registry.npmjs.org/@aws-cdk/assert/-/assert-1.69.0.tgz",
      "integrity": "sha512-VGjF1sNx05ez5/dwQ8Gn1Bc72X4Tjg1zOPRXq/1LOan2PFWz7WiwHvpww85dRWK1N0R462k6ntUshU8U3TSOBA==",
      "dev": true,
      "requires": {
        "@aws-cdk/cloud-assembly-schema": "1.69.0",
        "@aws-cdk/cloudformation-diff": "1.69.0",
        "@aws-cdk/core": "1.69.0",
        "@aws-cdk/cx-api": "1.69.0",
        "constructs": "^3.0.4"
      }
    }

If I lock my dependencies by removing the hat symbols ^ from versions e.g.:

"devDependencies": {
    "@aws-cdk/assert": "1.68.0",
    "aws-cdk": "1.68.0",
  },
  "dependencies": {
    "@aws-cdk/aws-waf": "1.68.0",
    "@aws-cdk/core": "1.68.0",
    "@aws-solutions-constructs/aws-cloudfront-s3": "1.68.0",
  }

Then it installs correctly:

"dependencies": {
    "@aws-cdk/assert": {
      "version": "1.68.0",
      "resolved": "https://registry.npmjs.org/@aws-cdk/assert/-/assert-1.68.0.tgz",
      "integrity": "sha512-KHL0Z+7jzGzpZnjlCXmGONS0nBecU4eMWOQaUaMXtzQ5iwEEMq/GCwdy59m0TM919UQi3RgPvGV+YPY/Laptxg==",
      "dev": true,
      "requires": {
        "@aws-cdk/cloud-assembly-schema": "1.68.0",
        "@aws-cdk/cloudformation-diff": "1.68.0",
        "@aws-cdk/core": "1.68.0",
        "@aws-cdk/cx-api": "1.68.0",
        "constructs": "^3.0.4"
      }
    },

we never use caret "^" for AWS packages. It brought us straight to hell several times...

Why is this closed?
This is a nightmare and still exists in 1.72

Getting the same error with my dependencies:

"devDependencies": {
    "@aws-cdk/assert": "^1.68.0",
    "aws-cdk": "^1.68.0",
  },
  "dependencies": {
    "@aws-cdk/aws-waf": "^1.68.0",
    "@aws-cdk/core": "^1.68.0",
    "@aws-solutions-constructs/aws-cloudfront-s3": "^1.68.0",
  }

Steps:

  • Removing node_modules
  • Removing package-lock.json
  • running npm install

Then looking at the package-lock.json I see it's install 1.69.0 somehow:

"dependencies": {
    "@aws-cdk/assert": {
      "version": "1.69.0",
      "resolved": "https://registry.npmjs.org/@aws-cdk/assert/-/assert-1.69.0.tgz",
      "integrity": "sha512-VGjF1sNx05ez5/dwQ8Gn1Bc72X4Tjg1zOPRXq/1LOan2PFWz7WiwHvpww85dRWK1N0R462k6ntUshU8U3TSOBA==",
      "dev": true,
      "requires": {
        "@aws-cdk/cloud-assembly-schema": "1.69.0",
        "@aws-cdk/cloudformation-diff": "1.69.0",
        "@aws-cdk/core": "1.69.0",
        "@aws-cdk/cx-api": "1.69.0",
        "constructs": "^3.0.4"
      }
    }

If I lock my dependencies by removing the hat symbols ^ from versions e.g.:

"devDependencies": {
    "@aws-cdk/assert": "1.68.0",
    "aws-cdk": "1.68.0",
  },
  "dependencies": {
    "@aws-cdk/aws-waf": "1.68.0",
    "@aws-cdk/core": "1.68.0",
    "@aws-solutions-constructs/aws-cloudfront-s3": "1.68.0",
  }

Then it installs correctly:

"dependencies": {
    "@aws-cdk/assert": {
      "version": "1.68.0",
      "resolved": "https://registry.npmjs.org/@aws-cdk/assert/-/assert-1.68.0.tgz",
      "integrity": "sha512-KHL0Z+7jzGzpZnjlCXmGONS0nBecU4eMWOQaUaMXtzQ5iwEEMq/GCwdy59m0TM919UQi3RgPvGV+YPY/Laptxg==",
      "dev": true,
      "requires": {
        "@aws-cdk/cloud-assembly-schema": "1.68.0",
        "@aws-cdk/cloudformation-diff": "1.68.0",
        "@aws-cdk/core": "1.68.0",
        "@aws-cdk/cx-api": "1.68.0",
        "constructs": "^3.0.4"
      }
    },

Add carets and then npm upgrade? As it stands, when you're saying "@aws-cdk/core": "1.68.0" (for example) you are saying "stick to this version even when I run npm upgrade". But adding the caret _will_ do what you want:

"@aws-cdk/core": "^1.68.0" (note the caret)

My intention was to lock the package versions to fix the bug with CDK versions. CDK is versioned incorrectly and breaking builds when new versions are released.

According to Semvar:

  • MAJOR version increment when you make incompatible API changes,
  • MINOR version increment when you add functionality in a backwards compatible manner
  • PATCH version increment when you make backwards compatible bug fixes.
    https://semver.org/

npm is designed to work in harmony with this:

Therefore with the default package.json versions as ^1.68.0 MINOR (backwards compatible) changes are automatically upgraded. That is how my package-lock.json showed installed version was actually 1.69.0 even though my package.json contained ^1.68.0

There are breaking changes from aws-cdk version 1.68.0 to 1.69.0. This should be a MAJOR version increment, OR we have to start telling folks to lock versions using ~1.68.0 or 1.68.0.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

farzad-xgen picture farzad-xgen  路  30Comments

eladb picture eladb  路  52Comments

jaapvanblaaderen picture jaapvanblaaderen  路  27Comments

rix0rrr picture rix0rrr  路  61Comments

PygmalionPolymorph picture PygmalionPolymorph  路  53Comments