Failure handling in groups and subroutines

[mike_laff]

I've used your product now for a few weeks to attempt produce a complex build of a number of projects. However, I find the error handling of groups and subroutines in general very confusing and in a complex project (with error handling!) it appears that groups and subroutines are relatively useless.

For example, in both groups and subroutines, exactly what effect do the "On Step Failure" properties do? Groups and subroutines never fail!

If this does nothing surely it should be removed (on groups/subs) to avoid confusion and time wasting trying to use them. However, use of these properties could be made valuable by extending them with an option to exit from the group/subroutine with a status. I believe this would be an extremely useful enhancement.

ie. Build failure steps: [ ] (blank for all)
(o) continue building or
(o) exit group/subroutine with success (?)
(o) exit group/subroutine with fail

For a basic example of why this would be used....

I wish to build 20 projects. Each project requires a version change, a VC build and a setup built. I create a subroutine to do these 3 steps (could be 10 or more in reality) and call the subroutine 20 times from the main project steps using parameters. Naturally, there is no point trying to build the setup if the VC build fails but I do wish the other 20 projects to be allowed their own attempt at building. With diligent use of the "Continue building" option and lots of conditional build rules, I have actually managed to achieve this but it was very cumbersome for a requirement that seems so basic.

Apart from this one semi-serious failing, however, it's a magic product - keep up the good work

[kinook]

Originally posted by mike_laff
I've used your product now for a few weeks to attempt produce a complex build of a number of projects. However, I find the error handling of groups and subroutines in general very confusing and in a complex project (with error handling!) it appears that groups and subroutines are relatively useless.

For example, in both groups and subroutines, exactly what effect do the "On Step Failure" properties do? Groups and subroutines never fail!

If this does nothing surely it should be removed (on groups/subs) to avoid confusion and time wasting trying to use them.

The On Step Failure settings apply to any step that fails, whether in a group or subroutine or not.

However, use of these properties could be made valuable by extending them with an option to exit from the group/subroutine with a status. I believe this would be an extremely useful enhancement.

ie. Build failure steps: [ ] (blank for all)
(o) continue building or
(o) exit group/subroutine with success (?)
(o) exit group/subroutine with fail

For a basic example of why this would be used....

I wish to build 20 projects. Each project requires a version change, a VC build and a setup built. I create a subroutine to do these 3 steps (could be 10 or more in reality) and call the subroutine 20 times from the main project steps using parameters. Naturally, there is no point trying to build the setup if the VC build fails but I do wish the other 20 projects to be allowed their own attempt at building. With diligent use of the "Continue building" option and lots of conditional build rules, I have actually managed to achieve this but it was very cumbersome for a requirement that seems so basic.

Apart from this one semi-serious failing, however, it's a magic product - keep up the good work

Not a bad idea. I suspect the reason it hasn't been requested before now are:
1) It's more common to do all that from a single step in VBP (a Make VC or Make VS.NET step to set/increment versions, specifying a workspace or solution containing all 20 projects + setup projects)

2) If broken out into multiple steps for each project, it's still probably more common to stop on any step failure and correct the problem before continuing (later projects will likely depend on the earlier ones, etc.).

3) Even when continuing, there probably aren't many steps that could fail and the build should still continue, so

what you could do: in the subroutine, mark the build step to continue on failure, and add an Exit step (configured to exit with a success status) after it with a build rule of

%LASTSTEP_STATUS% does not equal 0

This will exit from the subroutine at that point if the build step failed, and the build will continue at the next project step.

If you do end up with several steps in the subroutine that should trigger an exit of the subroutine on failure, you could get more elaborate and use project-level step script events to store the status and conditionally skip the remaining steps.
http://www.visualbuild.com/Manual/scriptevents.htm

[mike_laff]

Hi, thanks for the feedback.

The On Step Failure settings apply to any step that fails, whether in a group or subroutine or not.

--- My point here is that subroutine/group steps (the step itself not the steps within) cannot fail as they do nothing. Therefore, is there any point to these failure step settings? I for one, nievely thinking that the subroutine failure settings would do something if the steps within the subroutine failed, wasted hours trying to use these settings. I think it would be helpful to save others the same trouble.

1) It's more common to do all that from a single step in VBP (a Make VC or Make VS.NET step to set/increment versions, specifying a workspace or solution containing all 20 projects + setup projects)

--- I'm unsure what you mean here. I'm trying to put together a single nightly build (1 .bld file) of around 30 big products.

The first part of my build process builds around 50 shared libraries/components - all the libraries are simple VC/VS builds, all the components use a subroutine to (a) update the version, (b) do a VC/VS Make and (c) update source control with new version. Any faillure in this part stop the build completely.

The second part of my build then builds the products themselves. Each product uses a subroutine to (a) update the version, (b) do a VC/VS Make and (c) update source control with new version. Some subroutines are much more complex. Most products also and have their own independant libraries/components. Here, I want every product to have an opportunity for building.

The third part of my build does the setups. Each setup uses a subroutine to (a) update the version, (b) do a Setup Make and (c) update source control with new version. Again, I want every setup to have an opportunity for building.

2) If broken out into multiple steps for each project, it's still probably more common to stop on any step failure and correct the problem before continuing (later projects will likely depend on the earlier ones, etc.).

--- I see you point, but I would imagine that a fair number of people would have projects similar to mine where we have a number of shared components/libraries (that do require a complete build stop) followed by a number of projects/products that should each have a chance of building in their own right. This can dramatically save time on big projects as you can potentially fix two (or more) problems without having to restart the build twice (or more!). This has been mentioned a few times in these forums in the past.

3) Even when continuing, there probably aren't many steps that could fail and the build should still continue, so

what you could do: in the subroutine, mark the build step to continue on failure, and add an Exit step (configured to exit with a success status) after it with a build rule of

%LASTSTEP_STATUS% does not equal 0

--- This does not work if you run any failure steps in the last step. By the time the Exit step gets to evaluate this status, the last failure step will have already modified the %LASTSTEP_STATUS% back to 0 - well, as long as the last failure step itself succeeded! This is exactly where I've had to add custom code (in every stepdone action) along with using my own status macro to be able to track the real status of the build and not including the failure steps. This is very cumbersome and why my previous suggestion would again save a lot of time and effort.

eg.

sub vbld_StepDone()
Set pmacro = Project.Macros("MYLASTSTEP_STATUS")
pmacro.Value = Step.BuildStatus
end sub

along with an exit step status with a build rule as you describe albeit, using my macro...

%MYLASTSTEP_STATUS% does not equal 0

Note. I actually find it simpler not to use the Exit step as you end up with it after every other step. it's much simpler, in this case, just to skip all subsequent actions using the following build rule on them all:

%MYLASTSTEP_STATUS% is equal to 0

[kinook]

Originally posted by mike_laff
Hi, thanks for the feedback.

My point here is that subroutine/group steps (the step itself not the steps within) cannot fail as they do nothing. Therefore, is there any point to these failure step settings? I for one, nievely thinking that the subroutine failure settings would do something if the steps within the subroutine failed, wasted hours trying to use these settings. I think it would be helpful to save others the same trouble.

The step could fail if the subroutine being called doesn't exist, an undefined macro is referenced, etc.

This does not work if you run any failure steps in the last step. By the time the Exit step gets to evaluate this status, the last failure step will have already modified the %LASTSTEP_STATUS% back to 0 - well, as long as the last failure step itself succeeded! This is exactly where I've had to add custom code (in every stepdone action) along with using my own status macro to be able to track the real status of the build and not including the failure steps. This is very cumbersome and why my previous suggestion would again save a lot of time and effort.

eg.

sub vbld_StepDone()
Set pmacro = Project.Macros("MYLASTSTEP_STATUS")
pmacro.Value = Step.BuildStatus
end sub

along with an exit step status with a build rule as you describe albeit, using my macro...

%MYLASTSTEP_STATUS% does not equal 0

Note. I actually find it simpler not to use the Exit step as you end up with it after every other step. it's much simpler, in this case, just to skip all subsequent actions using the following build rule on them all:

%MYLASTSTEP_STATUS% is equal to 0

You should be able to use FAILSTEP_STATUS in that case.
http://www.visualbuild.com/Manual/systemmacros.htm

Also, as mentioned, if your logic is complex enough to need script events, you should be able to utilize *project-level* script events (i.e., vbld_StepDoneProject) to do it in one place.
http://www.visualbuild.com/Manual/scriptevents.htm

[mike_laff]

Ok thanks. I can see you're not really interested in feedback.

[kinook]

We actually are. But since we can't implement your feature request tomorrow, I thought you might want to know about options that are available now.


Admin note: Implemented in v6.4