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

[object]

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]

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]

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]

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]

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]

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

getBuildParamOrDefault was good.

[matthid]

Maybe like #2288?