Fake writes its version string to stderr when -v is given

[tebeco]

Description

It feels like the ouput of Fake build (probably the line with the version) is detected as a Build error
At the very begining of the the build (even before the restore step) the build goes from Green to red

Expected behavior

The build should not detect "Some" lines as error when it feels like it is just "Verbosity"

Actual behavior

As it is delicate for me to output code from the company here is what the build log looks like

Known workarounds

Manually open the log for each TeamCity build ...

Related information

• Operating system - Win2016
• The code targets, for the CLI, that's a good question, i use fake-cli as a dotnet-tool
• Severity : Critical (cannot dissociate Success or failure)
• Version of FAKE 5.4.x

the script is ran using a Powershell PS1 :

function Invoke-FakeBuild([string]$TargetName) {
    $fakeBuildArgs = "./$($fakeCli) -v run $($BuildScript) --no-cache --parallel 8 --target $($TargetName)"

    if ($SkipUnitTests -or $SkipIntegrationTests) {
        $fakeBuildArgs += " --"

        # Only set switch this for testing Pack/Push for the Fake script
        if ($SkipUnitTests) {
            $fakeBuildArgs += " --skip-unit-tests"
        }

        # Only set switch this for testing Pack/Push for the Fake script
        if ($SkipIntegrationTests) {
            $fakeBuildArgs += " --skip-integration-tests"
        }
    }

    Write-Host "Execution expression : '$($fakeBuildArgs)'"
    Invoke-Expression $fakeBuildArgs
}

Invoke-FakeBuild -TargetName $TargetName

As you can see i do not read the exit code of the Fake Build in order to let the powershell return the good exit good.

So far it ALWAYS return 0 (so in this scenario it should not affect the build result)

Finding the cullprit

Redirect StdErr to another stream :

Invoke-Expression "$($fakeBuildArgs) 2>error.log"

> cat .\error.log
FAKE 5 - F# Make (5.4.0)

not sure this is this line, because i still don't find where it is being printed out
https://github.com/fsharp/FAKE/blob/staging_5_4/src/app/Fake.Runtime/Environment.fs#L12

[kblohm]

Have you tried adding TeamCity as a BuildServer? As in

BuildServer.install [
    TeamCity.Installer
]

I am using FAKE with teamcity and it is working just fine for me.

[tebeco]

here is a little update to the script fake boostrap :

function Invoke-FakeBuild([string]$TargetName) {
    $fakeBuildArgs = "./$($fakeCli)"
    $runArgs = " run $($BuildScript) --no-cache --parallel 8 --target $($TargetName)"

    if ($FakeVerbose) {
# THIS IS THE ORIGIN OF THE ERROR
        $fakeBuildArgs += " -v"
# THIS IS THE ORIGIN OF THE ERROR
    }

    $fakeBuildArgs += $runArgs

    Write-Host "Execution expression : '$($fakeBuildArgs)'"
    Invoke-Expression "$($fakeBuildArgs) 2>error.log"
}

Invoke-FakeBuild -TargetName $TargetName

[tebeco]

@kblohm at the begining of the script i guess ?

[tebeco]

@kblohm
can you try with fake -v run ?

[tebeco]

@kblohm, i just rollbacked this

if TeamCity.detect() then
  Trace.log "Installing Teamcity BuildServer"
  BuildServer.install [TeamCity.Installer]
else
  Trace.log "Teamcity not detected"

as it completly destroy the Teamcity logs in the UI, tons of line ending does not render, it was way worse ;)

using teamcity 10.0.x

[matthid]

I updated the description. I'm not exactly sure if this is actually a bug or by design. I guess I'll have to think about it and compare to other tools. But I think other tools do the same.

In fact: We might even decide to write a lot more into stderr in order to have deterministic output on stdout with and without -v flag (ie only stderr would be different)

On the other hand we don't really have deterministic output anyway. If you want that you would use -s (silent). Anyway: Workaround is to disable "fail on standard error" in TeamCity or do not use -v.

[matthid]

One other thing we write to stderr (which would make your build red) is warnings (https://github.com/fsharp/FAKE/blob/release/next/src/app/Fake.netcore/Program.fs#L160). But that might be exactly what you want?

[matthid]

Ok I'm fine with changing this particular behavior...

[tebeco]

thx for the title, that's a good idea

I'm also fine removing the -v, i added it so we would have maximum info while building, but i it might be not that important on the CI
Should i run my CI/CD with -v on all run ? or should it be really on few occasion

I feel like i'm going to remove the -v if you confirm it will help us fix build issue on really few occasion

side note, if you'd like deterministic build output you can also format stdout kinda like logs framwork does when outputing to the console

[matthid]

Yes please remove -v. Verbose is basically a fallback if you want to debug fake itself and need to know exactly what's going on (there is even -vv if -v is not enough). As long as you don't have any issues going without -v is the suggested way to use fake.

In fact, because -v is so verbose we have a more lightweight way to debug issues without using -v which is to set the environment variable FAKE_DETAILED_ERRORS to true. This will only add more details when an error happens and be "normal" otherwise.

[tebeco]

ok, thx for the answer

i'll keep my powershell switch but defaulted to false so that the CI won't use -v by default

I let you decide what to do with this issue, depending if you still need to keep it open for the stdout/err feature, or just close it. Now i understand a bit more the behavior ;)

Thx for all the details

[matthid]

Yes, I think I'll not consider this a bug but improve the behavior by changing the message we print to stderr a bit.

For example:

FAKE 5 - F# Make (version) running in verbose mode (this line is written to standard error, see https://github.com/fsharp/FAKE/issues/2066)

This has the "advantage" that you can "test" what your CI is doing when something is written to standard error. This seems reasonable for verbose mode.

[tebeco]

thx for all the precision