(pipelines): SelfMutate loads notices by default #19542
Comments
Kruspe
added
bug
|
If you agree with my assumptions I can provide a PR to fix this. |
|
Unfortunately adding What version of the CLI are you using? We've reduced the timeout so the delay should not be noticeable anymore. |
rix0rrr
added
the
response-requested
|
Yeah I see that problem. What we could do is a version check. We are not providing a cliVersion so we are using the latest version (2.17.0). I saw the PR but it does not seem to do what it is suppose to do. 🤔 |
github-actions
bot
removed
the
response-requested
|
Hi, @Kruspe. How does npm install the latest version when it doesn't have access to the internet? Are you using CodeArtifact? Can you please confirm the version by looking at the debug output? It's the first line. |
|
We are using a proxy to download the necessary things and are providing a list of whitelisted urls. NPM is Part of it but the notices endpoint is not. |
|
@rix0rrr & @otaviomacedo any thoughts on this? |
In an environment where DNS resolution works but network packets may be
dropped, the CLI can hang for up to 15 minutes trying to refresh
notices. We tried to set a timeout of 3 seconds on this, but did it in a
way that didn't work.
Turns out that the `request.on('timeout')` event in NodeJS doesn't actually stop
the request: it just notifies the listener that it's been a long time
since we saw network bytes, leaving the listener to do with that
what they want (potentially show a dialog box to a waiting user or
whatever). In our case, we had to do an additional `request.destroy()`
to actually stop the request.
Without doing this, the Promise would resolve correctly and the CLI
would continue, but the actual HTTP request would still be going on
in the background, preventing Node from shutting down.
This PR also changes the behavior of reporting a download failure: it
used to be that we would successfully resolve to a `[]` response if
the HTTP request failed (which would then be cached). Instead, after
this change we reject the Promise if anything goes wrong, so that the
next invocation will try again.
Fixes #19542.
In an environment where DNS resolution works but network packets may be
dropped, the CLI can hang for up to 15 minutes trying to refresh
notices. We tried to set a timeout of 3 seconds on this, but did it in a
way that didn't work.
Turns out that the `request.on('timeout')` event in NodeJS doesn't actually stop
the request: it just notifies the listener that it's been a long time
since we saw network bytes, leaving the listener to do with that
what they want (potentially show a dialog box to a waiting user or
whatever). In our case, we had to do an additional `request.destroy()`
to actually stop the request.
Without doing this, the Promise would resolve correctly and the CLI
would continue, but the actual HTTP request would still be going on
in the background, preventing Node from shutting down.
This PR also changes the behavior of reporting a download failure: it
used to be that we would successfully resolve to a `[]` response if
the HTTP request failed (which would then be cached). Instead, after
this change we reject the Promise if anything goes wrong, so that the
next invocation will try again.
Fixes #19542.
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
In an environment where DNS resolution works but network packets may be
dropped, the CLI can hang for up to 15 minutes trying to refresh
notices. We tried to set a timeout of 3 seconds on this, but did it in a
way that didn't work.
Turns out that the `request.on('timeout')` event in NodeJS doesn't actually stop
the request: it just notifies the listener that it's been a long time
since we saw network bytes, leaving the listener to do with that
what they want (potentially show a dialog box to a waiting user or
whatever). In our case, we had to do an additional `request.destroy()`
to actually stop the request.
Without doing this, the Promise would resolve correctly and the CLI
would continue, but the actual HTTP request would still be going on
in the background, preventing Node from shutting down.
This PR also changes the behavior of reporting a download failure: it
used to be that we would successfully resolve to a `[]` response if
the HTTP request failed (which would then be cached). Instead, after
this change we reject the Promise if anything goes wrong, so that the
next invocation will try again.
Fixes aws#19542.
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
What is the problem?
When using the SelfMutate step it calls
cdk -a ${toPosixPath(embeddedAsmPath(this.pipeline))} deploy ${pipelineStackIdentifier} --require-approval=never --verbose. With the new cdk release this fetches notices. If the SelfMutate runs in a private subnet without internet connection the step takes really long until the request times out. (Build times go up from 2 minutes to 16 minutes).Reproduction Steps
Create a pipeline which uses the SelfMutate option and runs in a private subnet.
What did you expect to happen?
For the SelfMutate I do not think that it is necessary to fetch the notices.
What actually happened?
The deploy step tries to fetch the notices.
CDK CLI Version
2.17.0
Node.js Version
16.14.0
OS
MacOS Monetery 12.3
Language
Typescript
I think it would suffice to add the
--no-noticesflag to the cdk deploy command.The text was updated successfully, but these errors were encountered: