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

WIP fix for shell script executable bit and scaffolding for template tests #1990

Merged
merged 6 commits into from
Jun 11, 2018

Conversation

baronfel
Copy link
Contributor

No description provided.

@baronfel
Copy link
Contributor Author

GAH! We can't actually set the executable bit because of a few outstanding templating/coreclr bugs: dotnet/templating#1547

However we should still add this because a) it'll be fixed at some point, and b) even if it fails it leaves a helpful error message:

The files /private/var/folders/80/y0q8bqgx29bd8g3h0tlt00k00000gn/T/mrisxb4t.jrn/chmod, /private/var/folders/80/y0q8bqgx29bd8g3h0tlt00k00000gn/T/mrisxb4t.jrn/+x, and /private/var/folders/80/y0q8bqgx29bd8g3h0tlt00k00000gn/T/mrisxb4t.jrn/*.sh do not exist.
Unable to apply permissions +x to "*.sh".
Post action failed.
Description: Make scripts executable
Manual instructions: Run 'chmod +x *.sh'

@matthid
Copy link
Member

matthid commented Jun 10, 2018

@baronfel I don't think we can expect them to change the behavior again, the flag just was used incorrectly all the years - I agree that using it like this is not portable at all. Therefore we should probably change to /bin/sh -c or /usr/bin/env sh -c

@baronfel
Copy link
Contributor Author

that's fair 👍

@baronfel
Copy link
Contributor Author

hard to test the run an executable action in an integration test though because the promtps require user input:

Template is configured to run the following action:
Description: Make scripts executable
Manual instructions: Run 'chmod +x *.sh'
Actual command: /bin/sh -c "echo pwd && chmod +x *.sh"
Do you want to run this action (Y|N)?

@baronfel
Copy link
Contributor Author

Ok, I've added a test for both the tool and project variants. It would be easy to write more. The hard part will be interacting with the tests because now we have to answer 'yes' for each test of the template. For this reason I've marked them pending but I think we should use them when working on the template locally for sure, at least until the input question is solved.

@matthid
Copy link
Member

matthid commented Jun 10, 2018

We can either try to set all options beforehand via command line or just redirect and write standard input

@matthid
Copy link
Member

matthid commented Jun 10, 2018

Apparently there is --allow-scripts yes, see dotnet/templating#765 (comment)
Seems to be undocumented for now as I cannot see it in --help

@@ -1,11 +1,75 @@
module Fake.Dotnet.Cli.IntegrationTests.TemplateTests
module Fake.DotNet.Cli.IntegrationTests.TemplateTests
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also rename the folder in git, otherwise there will be problems (which is a bit unfortunate to do on windows as you have to temporarily rename to something else)

@baronfel
Copy link
Contributor Author

Ok, I did it via redirecting stdin

x.WithWorkingDirectory(dir)
.WithFileName(fullScriptPath)
.WithArguments "--help" ) (System.TimeSpan.FromSeconds 60.)
|> shouldSucceed "should invoke the script file"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer a test which actually checks if ./fake build works (ie all dependencies still work)
Also can we add a failing test (ie that the scripts correctly return nonzero exit-codes on failure). For example by executing ./fake.sh run nonexisting.fsx.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a test around ./fake.sh build -t All and ./fake.sh build -t Nonexistent

)

proc.Start () |> ignore
do! Async.Sleep 2000
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was guessing at how long to wait after invoking the template gen, so that the prompt would be active at the point that I sent the Y character.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you try --allow-scripts yes (not the most important - but I guess it would not introduce a potential race condition)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I'll give that a try when I add the new tests

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

worked like a charm.

@matthid
Copy link
Member

matthid commented Jun 10, 2018

Thanks a lot for taking care of this! Just two more things I noticed.

@baronfel
Copy link
Contributor Author

Alright, if this is green I think we're in a better place.

@baronfel
Copy link
Contributor Author

Is there anything else here I missed that you'd like me to cover?

@matthid
Copy link
Member

matthid commented Jun 11, 2018

Only the one comment, but otherwise looks good

@baronfel
Copy link
Contributor Author

I'm sorry, which comment do you mean? I thought I just needed to look into --allow-scripts (which we're now using successfully) and adding some more tests around the positive/negative template-script uses (which I added).

Copy link
Member

@matthid matthid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I forgot to actually submit the review, sorry ;)

Directory.ensure tempDir
runTemplate tempDir Project
let result = invokeScript tempDir scriptFile "build -t Nonexistent"
Expect.isFalse (result.OK && missingTarget "Nonexistent" result) "Should fail to build a target that doesn't exist"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think because result.OK is false missingTarget will not be executed.
What we want is probably 'isTrue(not OK && missingTarget)'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah you are of course correct. I updated the test checks to be more clear about the two conditions.

@baronfel baronfel force-pushed the executable_scripts branch from 5b611ad to e02f56c Compare June 11, 2018 20:39
Copy link
Member

@matthid matthid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matthid
Copy link
Member

matthid commented Jun 11, 2018

Oh we do not actually run the new tests in the build process, do we?

@baronfel
Copy link
Contributor Author

ah yeah. I'm looking at how to place them post-dotnet-pack right now.

@matthid
Copy link
Member

matthid commented Jun 11, 2018

You can also integrate it into the DotNetCoreIntegrationTests just call dotnet run like the others

@baronfel
Copy link
Contributor Author

Yeah but I'm relying on the pack task having packaged the nuget package, so I can just install it. That seems harder to orchestrate than just running the template tests sometime after packaging. What do you think?

@matthid
Copy link
Member

matthid commented Jun 11, 2018

Ah yeah whatever you think is easier :)

@baronfel
Copy link
Contributor Author

baronfel commented Jun 11, 2018

Ok, I think I got them. The template tests are a little fragile (meaning towards future changes) because they point to the nuget directory precisely, but they do actually get invoked now.

@matthid
Copy link
Member

matthid commented Jun 11, 2018

Thanks a lot for taking care of this thing!

@matthid matthid merged commit 8064d42 into fsprojects:release/next Jun 11, 2018
@rmunn
Copy link
Contributor

rmunn commented Jun 14, 2018

dotnet/templating#1547 has been fixed by dotnet/templating#1555, so I suspect it'll be in the next .Net Core bugfix release. But since version 2.1.300 was released with the bug in it, it'll be a while before it's safe to use the chmod post-action (the one with GUID cb9a6cf3-4f5c-4860-b9d2-03a574959774) and trust that it'll work on everyone's system.

@baronfel baronfel deleted the executable_scripts branch June 19, 2018 16:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants