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

Environment variables passed in command line are not evaluated until targets execution #2283

Closed
object opened this issue Mar 19, 2019 · 6 comments

Comments

Projects
None yet
3 participants
@object
Copy link

commented Mar 19, 2019

Description

If I pass custom build parameters using "-e" switch they are not evaluated until targets are selected for execution. This makes it impossible to configure conditional target execution based on command line parameters.

Repro steps

Let's say I have a script that contains the following lines:

let skipTests = Environment.environVarAsBoolOrDefault "skipTests" false

"Start"
  =?> ("Clean", true)
  =?> ("Build", true)
  =?> ("RunTests", not skipTests)

I run the script:

fake run build.fsx --target All -e skipTests=true

Expected behavior

I expect "skipTests" to be evaluated at the time target execution is decided, i.e. the statement
("RunTests", not skipTests) should be evaluated as skipping "RunTests" target.

Please provide a description of the behavior you expect.

Actual behavior

At the time ("RunTests", not skipTests) is evaluated, skipTests is "false". Only inside the actual RunTests target execution "skipTests" is evaluated to "true".

Related information

  • Operating system: Windows
  • .NET 4.61/.NET Core
  • FAKE 5
@matthid

This comment has been minimized.

Copy link
Collaborator

commented Mar 19, 2019

Yes, basically this part of the command line is evaluated when Target.run is executed. Question is how we could move that to the top of the file, for example via some new function?

@object

This comment has been minimized.

Copy link
Author

commented Mar 19, 2019

IMHO it would make sense to enable evaluation of environment variable early. Current behavior doesn't look consistent for two reasons.

  1. Other parameters are evaluated early. For example, TeamCity.Environment.BuildNumber.IsSome is evaluated instantly, while Environment.environVarXXX functions are delayed until Target.run.

  2. If a variable is set at OS level, then prior Target.run OS environment variable values are evaluated, so the script can encounter two different values: one coming from OS before command line is evaluated, second after Target.run is invoked.

I haven't inspected the implementation but what makes it delay evaluation of environment values sent via command line? It would makes things more consistent if they became available at the beginning of the script execution.

@object

This comment has been minimized.

Copy link
Author

commented Mar 19, 2019

And if it's hard to make environment variables evaluated at the very beginning of the script, at least there should be a way to evaluate them in a target dependency section, so "condition" part can be specified as a predicate, not only a boolean value. This will still leave inconsistent mismatch between OS-level variables and command line variables, as described in p.2 above.

@matthid

This comment has been minimized.

Copy link
Collaborator

commented Mar 21, 2019

I haven't inspected the implementation but what makes it delay evaluation of environment values sent via command line?

It's basically the split of the command line. The script arguments (which includes the -e) are evaluated by the script. Currently this is part of the Target.run call at the end of your script.

And if it's hard to make environment variables evaluated at the very beginning of the script, at least there should be a way to evaluate them in a target dependency section, so "condition" part can be specified as a predicate, not only a boolean value.

Yes that was my suggestion: Add a new API which can be called at the top of the script. At least that would be the easiest approach afaics.

One other workaround/related feature now in Fake 5 is you add your very own CLI: https://fake.build/core-commandlineparsing.html

@Szer

This comment has been minimized.

Copy link

commented Mar 24, 2019

Supporting this issue.
WIth FAKE 5 I have to create my own CLI just for passing some parameters.

getBuildParamOrDefault was good.

@matthid

This comment has been minimized.

Copy link
Collaborator

commented Apr 4, 2019

Maybe like #2288?

@matthid matthid closed this in #2288 Apr 8, 2019

@matthid matthid referenced this issue Apr 8, 2019

Merged

Release 5.13.0 #2279

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.