-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
‼️ NOTICE: 'Error: ENOTDIR invalid cwd' on cdk deploy
in 1.90.0
#13131
Comments
Facing same issue with me as well |
I get the same error when trying to deploy a simple static website:
Version is also 1.90.0. Everything works when downgrading to 1.89.0. |
I've noticed the same problem when using a BucketDeployment. The zip exists at the path and contains awscli.
|
Confirming I was able to reproduce this. We're working on a fix. |
cdk deploy
cdk deploy
cdk deploy
in 1.90.0
Are we missing some test cases to prevent this from happening again? |
If everyone (or some) who are seeing this issue can comment with the node version they are using, it will help us debug it. Thanks! |
I am using node v14.15.0 |
Node v14.15.5 for us, which is the latest default node version on GitHub Actions Linux Agents and Azure DevOps Linux Agents (per https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md). |
Help! Using Cloud9 to deploy this stack fails https://github.com/aws-samples/faropt worked until last week and have tested in few regions now Node v10.23.3 Trace is Do you wish to deploy these changes (y/n)? y |
@w601sxs an you verify the CDK version? and that you are not using 1.90, which we suspect have the bug? |
im using v15.8.0, after also seeing this problem with a brew installed node v14 |
@bigkraig which CDK version? |
my bad, 1.90.0 |
@bigkraig would you mind verifying that it works with 1.89? I suspect it will not, and the problem is actually in one of our transient dependencies |
@NetaNir i actually had tried to do that right away but ran into a NPM dependency nightmare that i ultimately didn't have time to keep beating my head against, vowing to wait until this PR was resolved. i'll see if i can get some time to look at this again but it might not be until my lunch tomorrow. |
@NetaNir , I can confirm my deployment worked with 1.89 |
Possibly related: #12536 |
I think @NetaNir is right that it has something to do with dependencies. Notes:
Also note some import conflicts may start to occur on existing code between:
Not sure if any of the above helps but if it does then Kudos! |
I'm seeing the error with: node v14.15.5
|
Can you verify that this is in fact the version of the CDK CLI (aws-cdk) used? |
Yes, that is how I got the version numbers.
|
Updating package configuration from: "@aws-cdk/aws-ec2": "^1.89.0", to "@aws-cdk/aws-ec2": "1.89.0", Fixed the problem for me. I'm not sure which is the culprit but I suspect it is the EC2 module (see my previous comment above). Using the ^ (Compatible with version) seems to have something to do with it. Has to be specifically 1.89.0 - though I have not tried this fix with 1.90.0... |
For me it was:
Otherwise, would there be a version that does not rely on node being installed? And can the cdk team include real end to end test cases deploying to a dummy aws account for stable releases? |
Thanks everyone, we found the problem and we are working on a fix. The problem was introduced in version |
Revert #13145 |
|
Added a workaround to the issue description, TL;DR: delete the A patch is on the way! |
@NetaNir @eladb found the bug and running After the first This is because staging doesn't rerun:
and the FileAssetPackaging is set in the staging private methods not in the constructor.
On it for a redo. This is only #13076. |
Thanks @jogold. No rush. We reverted the other commit just because there were some merge conflicts. |
Yes, I can confirm it's 1.89 And I can confirm that deleting the cdk.out directory works for 1.89 as well |
node v12.20.1 |
|
Redo of #13076 after #13131. The fix is [`7b3d829` (#13152)](7b3d829). If the bundling output contains a single archive file (zip or jar), upload it as-is to S3 without zipping it. Allow to customize this behavior with `bundling.outputType`: * `NOT_ARCHIVED`: The bundling output will always be zipped and uploaded to S3. * `ARCHIVED`: The bundling output will not be zipped. Bundling will fail if the bundling output doesn't contain a single archive file. * `AUTO_DISCOVER`: If the bundling output contains a single archive file (zip or jar) it will not be zipped. Otherwise it will be zipped. This is the default. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Deleting cdk.out directory did not work
cdk and module versions
|
Please add your +1 👍 to let us know you have encountered this
Update
Version
1.90.1
which includes a fix is now released.There is an issue with the way the CDK assets mechanism identifies already
.zip
file. Currently it will try to zip the already zipped file that will throw an error. We are working on a fix.Workaround
TL;DR: delete the
cdk.out
folder before executingcdk deploy
The issue occurs when executing
cdk deploy
when there is a.zip
file in thecdk.out
folder. This happens when executingcdk synth
- which creates thecdk.out
folder, followed bycdk deploy
(which is a completely normal cdk flow). To workaround this, delete thecdk.out
folder before executingcdk deploy
.Repro
Any application which includes an asset with a
.zip
file will fail to deploy:important: execute
cdk synth
before executingcdk deploy
cdk deploy
will throw:Status: Working on a patch release
Overview:
When running
cdk deploy
in version1.90.0
on a Stack that contains assets, you might see an error like'Error: ENOTDIR invalid cwd
.Complete Error Message:
Original bug report
My CDK script was all right, but was failing with the latest 1.90.0 version
Reproduction Steps
Run the CDK script via gitlab pipeline
What did you expect to happen?
No errors
What actually happened?
See the error message as below:
Environment
Other
Rollback to 1.89.0 fixed the problem
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: