FAKE5 Targets always complete as "Failed"

[BlythMeister]

Description

The logging of a target always finished with "Finished (Failed) 'TargetName' in

It would appear the the default state on tracing is Failed, and this is never set to success in the target helper if it runs to completion.

[matthid]

Can you elaborate a bit I don't get it. Maybe a screenshot/sample/command line you use would help?

[BlythMeister]

Sure, our scripts are open source, so if you look at this repo https://github.com/15below/Build.Tools/tree/NewTools
Main.fsx is the entry point, and at the moment the targets are all empty.
When these run you always get the following logs.

Started
No description
Finished

[BlythMeister]

Looking at the logs for https://ci.appveyor.com/project/matthid/fake-6w516/build/1.0.1571 it would seem that you get (Success).

I wonder if there is something in the code for the target which sets the status...
However, I think If you do the simple hello world from https://fake.build/fake-gettingstarted.html you will get that symptom

[sliepie]

I've seen the same after upgrading to rc012, while running the following snippet:

Target.create "Bootstrap" (fun _ ->
    Trace.setBuildNumber (sprintf "%s-%s" buildNumber branchName)
)

Output:

[matthid]

So it seems to be a minor annoyance - fake printing the wrong stuff, correct?

[matthid]

I think this is related to 9d29f00. Idea is to report "tasks" as failed when _.MarkSuccess() is not called (which indicates an exception). Seems like I have missed some places there.

[sliepie]

@matthid correct it is a minor issue, as build passes fine.

[kblohm]

Instead of using a disposable, cant u just wrap everything in a function that forces u to return succes/failure and handle the try catch finally inside whatever calls the function. That way you cant forget to call MarkSucces(). I am pretty sure most people will just forget to call it.

As in Trace.traceTask "MyOperation" "Description" <| fun () -> TagStatus.Success
That would of course be a breaking change though.

[matthid]

That would of course be a breaking change though.

Yes we could add that as additional API, because we no longer do breaking changes at this point.

[matthid]

Actually I failed two times because the default should be Warning instead of Error. Now Warning isn't used at all :)

[BlythMeister]

Can someone please explain how I should be writing the target then to use mark success. As I'm a bit confused and can't see in docs

[matthid]

Sorry I didn’t make that clear. I think it is an internal bug. Just tried to clarify the issue and reasoning if someone wants to step in

[BlythMeister]

But if I have a target which I only do private stuff in, I don't want it to report warning if it was ok.

Imo, if it has an error thrown, it's error.
If it doesn't, its success...

[matthid]

Ok but it’s not so easy to detect. But yeah I guess we just need to fix this bug and it will be fine again

[BlythMeister]

Psudo code:

Try
execute target
Mark success
With
Mark failure
Throw

Might not even need the with as default is failure

[matthid]

I found the problem and it is fixed with rc13