Skip to content
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

Merged
merged 8 commits into from Sep 9, 2022

Conversation

TheRealAmazonKendra
Copy link
Contributor

@TheRealAmazonKendra TheRealAmazonKendra commented Jul 8, 2022

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 #18803.


All Submissions:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@gitpod-io
Copy link

gitpod-io bot commented Jul 8, 2022

@github-actions github-actions bot added the p2 label Jul 8, 2022
@aws-cdk-automation aws-cdk-automation requested a review from a team July 8, 2022 05:21
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Jul 8, 2022
@TheRealAmazonKendra TheRealAmazonKendra added p1 and removed p2 labels Jul 8, 2022
packages/aws-cdk/lib/init.ts Outdated Show resolved Hide resolved
packages/aws-cdk/lib/init.ts Outdated Show resolved Hide resolved
} else {
reject(new Error(`${renderCommandLine(command)} exited with error code ${code}`));
reject(new Error(`${options.errorMessage} exited with error code ${code}`));
Copy link
Contributor

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.

Copy link
Contributor Author

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) {
Copy link
Contributor

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?

Copy link
Contributor

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.' });
Copy link
Contributor

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.

packages/aws-cdk/test/init.test.ts Outdated Show resolved Hide resolved
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,
Copy link
Contributor

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?

packages/aws-cdk/lib/init-templates/app/util/os.ts Outdated Show resolved Hide resolved
…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.
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/init-template-fix branch from 09b7e2f to 0960e90 Compare September 3, 2022 02:08
@TheRealAmazonKendra
Copy link
Contributor Author

@Mergifyio update

@mergify
Copy link
Contributor

mergify bot commented Sep 9, 2022

update

✅ Branch has been successfully updated

@mergify
Copy link
Contributor

mergify bot commented Sep 9, 2022

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).

@TheRealAmazonKendra
Copy link
Contributor Author

@Mergifyio update

@mergify
Copy link
Contributor

mergify bot commented Sep 9, 2022

update

☑️ Nothing to do

  • #commits-behind>0 [:pushpin: update requirement]
  • -closed [:pushpin: update requirement]

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: a2089d1
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Sep 9, 2022

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).

@mergify mergify bot merged commit 79c9ca1 into main Sep 9, 2022
@mergify mergify bot deleted the TheRealAmazonKendra/init-template-fix branch September 9, 2022 12:30
Kruspe pushed a commit to DavidSchwarz2/aws-cdk that referenced this pull request Sep 13, 2022
…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*
rix0rrr added a commit that referenced this pull request Sep 19, 2022
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.
iliapolo added a commit that referenced this pull request Sep 19, 2022
mergify bot pushed a commit that referenced this pull request Sep 19, 2022
rix0rrr added a commit that referenced this pull request Sep 19, 2022
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.
iliapolo added a commit that referenced this pull request Sep 19, 2022
mergify bot pushed a commit that referenced this pull request Sep 20, 2022
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*
hacker65536 pushed a commit to hacker65536/aws-cdk that referenced this pull request Sep 30, 2022
…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*
hacker65536 pushed a commit to hacker65536/aws-cdk that referenced this pull request Sep 30, 2022
hacker65536 pushed a commit to hacker65536/aws-cdk that referenced this pull request Sep 30, 2022
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*
homakk pushed a commit to homakk/aws-cdk that referenced this pull request Dec 1, 2022
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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. p1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants