-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix(init-templates): csharp and fsharp app init fails when path contains space #21049
Conversation
} else { | ||
reject(new Error(`${renderCommandLine(command)} exited with error code ${code}`)); | ||
reject(new Error(`${options.errorMessage} exited with error code ${code}`)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This used to say something like
dotnet add bla exited with error code 1
And will now say
Could not add project project.fsproj to solution project.sln exited with code 1
This is hiding information now, we can't tell the command line anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pulled this from what we were actually outputting in the original version of the hook file, which was
reject(new Error(`Could not add project %name.PascalCased%.csproj to solution %name.PascalCased%.sln. Error code: ${code}`));
Both pieces of context are probably helpful in this case so I'll combine the two for the error message.
@@ -24,30 +22,26 @@ export async function shell(command: string[], options: ShellOptions = {}): Prom | |||
|
|||
// Both write to stdout and collect | |||
child.stdout.on('data', chunk => { | |||
if (!options.quiet) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did the quiet
feature get removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(If it's because it was unused and you took the opportunity to clean up a bit, please describe that in the PR so reviewers don't have to guess. I usually add an "Also in this PR..." section for those)
}); | ||
}); | ||
}; | ||
await shell(['dotnet', 'sln', slnPath, 'add', csprojPath], { errorMessage: 'Could not add project %name.PascalCased%.csproj to solution %name.PascalCased%.sln.' }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the advantage of adding the errorMessage
feature over just adding a try/catch
here?
Seems more orthogonal to leave it to consumer to decide how to handle errors.
const child = child_process.spawn(command[0], command.slice(1), { | ||
export async function shell(command: string[], options: ShellOptions): Promise<string> { | ||
const child = child_process.spawn(command[0], renderArguments(command.slice(1)), { | ||
shell: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why shell: true
?
What happens if we don't pass this command through the shell?
…space When running or with a space in the path to the project, init will fail. This fix adds in handling for spaces and other special characters in the filepath for both windows systems and posix systems. Tests have been added for posix and manual testing was performed on a windows machine. Closes issue #18803.
09b7e2f
to
0960e90
Compare
@Mergifyio update |
✅ Branch has been successfully updated |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
@Mergifyio update |
☑️ Nothing to do
|
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…ins space (aws#21049) When running `cdk init --language=csharp` or `cdk init --language=fsharp` with one or more spaces in the path to the project, `init` will fail. This fix adds in handling for spaces and other special characters in the file path for both windows systems and posix systems. This PR moves the temporary hook directory to the same directory as the source directory so that it can use the local `os.ts` file and other dependencies. `ShellOptions` was also removed because it wasn't used. Tests have been added for posix and manual testing was performed on a windows machine. Closes issue aws#18803. ---- ### All Submissions: *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Historically, `cdk init` used to create a dedicated temporary directory for hook scripts and copy `*.hook.*` scripts into there. In #21049, the logic was changed to create that temporary directory inside the CLI source directory. If that CLI source directory is mounted in a read-only location (say, `/usr/lib/node_modules`) then that directory could not be created and `cdk init` would fail. It looks like historically we might copy and postprocess hook scripts so that they could have variables replaced... but given that hook scripts are code, they could just read the variables directly, so we don't have to copy them into a temporary directory at all: we can directly run them from the source location. Fixes #22090.
Historically, `cdk init` used to create a dedicated temporary directory for hook scripts and copy `*.hook.*` scripts into there. In #21049, the logic was changed to create that temporary directory inside the CLI source directory. If that CLI source directory is mounted in a read-only location (say, `/usr/lib/node_modules`) then that directory could not be created and `cdk init` would fail. It looks like historically we might copy and postprocess hook scripts so that they could have variables replaced... but given that hook scripts are code, they could just read the variables directly, so we don't have to copy them into a temporary directory at all: we can directly run them from the source location. Fixes #22090.
Historically, `cdk init` used to create a dedicated temporary directory for hook scripts and copy `*.hook.*` scripts into there. In #21049, the logic was changed to create that temporary directory inside the CLI source directory. If that CLI source directory is mounted in a read-only location (say, `/usr/lib/node_modules`) then that directory could not be created and `cdk init` would fail. Historically, hook scripts were arbitrary scripts outside the scope of the CLI, but the previous change tried to reuse code from the CLI. That does not work because the CLI is now being bundled (all code and dependencies in one giant `.js` file), so reusing from the outside using a different entry point cannot work. (It's not clear that this is happening because we leave the source files in the original location inside the NPM package, to try and halfway not break people using the CLI in ways that are unsupported but happen to work). Instead, bundle the hook logic into the CLI itself, so it all uses the same mechanism. Fixes #22090. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Historically, `cdk init` used to create a dedicated temporary directory for hook scripts and copy `*.hook.*` scripts into there. In aws#21049, the logic was changed to create that temporary directory inside the CLI source directory. If that CLI source directory is mounted in a read-only location (say, `/usr/lib/node_modules`) then that directory could not be created and `cdk init` would fail. Historically, hook scripts were arbitrary scripts outside the scope of the CLI, but the previous change tried to reuse code from the CLI. That does not work because the CLI is now being bundled (all code and dependencies in one giant `.js` file), so reusing from the outside using a different entry point cannot work. (It's not clear that this is happening because we leave the source files in the original location inside the NPM package, to try and halfway not break people using the CLI in ways that are unsupported but happen to work). Instead, bundle the hook logic into the CLI itself, so it all uses the same mechanism. Fixes aws#22090. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
When running
cdk init --language=csharp
orcdk init --language=fsharp
with one or more spaces in the path to the project,init
will fail. This fix adds in handling for spaces and other special characters in the file path for both windows systems and posix systems.This PR moves the temporary hook directory to the same directory as the source directory so that it can use the local
os.ts
file and other dependencies.ShellOptions
was also removed because it wasn't used.Tests have been added for posix and manual testing was performed on a windows machine.
Closes issue #18803.
All Submissions:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license