OK, I just found another example where errors are missing in higher-level actions.
This time it was stopped further up, as well as the ActionList/Target also stopped.
Last time the File Compare failed, if I remember correctly, which was red but not visible because it was folded up,
but the complete ActionList/Target was unfortunately “Completed”.
There is no finalbuilder bugreport.txt in %temp%.
But I’ll send the huge FBL8 by email.
This looks normal to me. Parent action run to completion before child actions run… so yes the child action failed, but that doesn’t mark the parent action (the group) as failed. It has always been that way.
The exception to that rule is Async Groups, Run Target and Include Project.
Unless I am misunderstanding what you are trying to show here?
Unless I am misunderstanding what you are trying to show here?
I had the feeling that in the past all ActionGroups had stopped and turned red as soon as an action failed underneath.
That’s right, just got the old FB7 out again and it was like that there.
I had never paid much attention to it before, but since I am currently revising our FB script, it had seemed strange to me, because I had the feeling that the behavior was different before,
but it only looked like this in two of our three central locations, since there happens to be an AsyncActionGroup being used.
First Error is ignored by ActionGroup, but it doesn’t happen with the second error.
This different behavior is a little bit confusing.
I would have expected that only the last raise would stop everything.
With the AsyncActionGroup errors are displayed in subordinate actions and “Ignore Failure” of the group ignores everything.
With the normal ActionGroup, and everything else, it only affects the actions themselves.
That explains why in some places the “Ignore Failure” in an ActionGroup doesn’t work as we expected.
For years we have had the problem that the FB script runs through in some projects because of “Ignore Failure” in the AsyncActionGroup,
shows “Build Successful” with the green check sign at the end, and the Error = 1 and Ignored = 1 are not seen.
Even with an error, few actions must currently be carried out, e.g. to start Delphi.
I’m trying to remove most of the “Ignore Failure”, but which would be easier if the OnFailure still existed.
Actually, it would not be necessary to ignore errors and then copy files, but it will take some time until these structural problems in our directory structure are fixed.
Note that the ability to run individual actions is only there as a debugging aid, not a normal mode of operation. We do not have the ability to bring back the OnFailure list, and for normal running of projects the try catch works fine.
No it has never worked like that. What you are seeing is due the fact that each immediate child under an Async Group runs in a separate thread (we create a pseudo target to run them on). When an error occurs in an action under the async group, the group is signalled to stop any other threads it’s running. The order in which they actually stop is up to windows. So the result’s can appear slightly random due to the nature of threading.
Tried it in the old FinalBuilder and yes, it has always been like this,
I just thought it would be different, as it happened that mostly AsyncActionGroups were involved when it came to errors.
Yes, it is only used for debugging.
It runs normally, but if there was an error, then e.g. Delphi repairs this project and then it is “continued” from this point in FinalBuilder.
In the future I will try to remove the necessary copying of files or to move this to the AfterBuildScript of MSBUILD.
But I can’t change everything at once and have to live with some old ways of working for the time being.
