#1
|
|||
|
|||
FAILSTEP_NAME not being set
The FAILSTEP_NAME does not seem to be set when an operation fails. Basic overview of my script is as follows..
STEP_1: Checks if any source files it needs are already checked out. If any files are checked out the script fails. To do this I am using a Visual Source Safe Action configured as a 'Status' operation. STEP_2..STEP_X: Check out and compile etc. I also have a conditional failure step in my script. The condition is based on whether it fails on 'Step 1' or elsewhere. I have tried checking the FAILSTEP_NAME in the failure step but its value is always blank. I assumed it should equal the 'Name' field in the properties dialog for STEP_1. Anybody know where I'm going wrong? I'm using Visual Build Pro v4.6b |
#2
|
|||
|
|||
I've noticed this too. Could it be that following the first step in the Failure Steps the name is reset? A work around would be to have the first step save the step name to a macro.
Most of my failure processing sends email. I send the log file for the build as an attachment to the email. Another trick I find useful is to use a global macro to override the system LOGFILE macro with: %LogFilePath%%PROJROOT%Log.txt so that log files are generated for each different build project. Helps a lot when a master build project invokes others. I also often use %PROJROOT% in the body of the email so I know which build project generated the email. Peter Jaquiery |
#3
|
|||
|
|||
Hello,
My experience has been that the FAILSTEP marcos are only available in the Failure Steps tab not in the Project Steps tab. Most of the time I don't want the build to stop on those step if they fail, rather I just record that they failed and move on to other steps. For those cases I use the LASTSTEP_STATUS macro to check the status and then record the name and output if there was a failure in the main Project steps tab. -Corey |
#4
|
|||
|
|||
I just came across this issue as well. We were using these values in the Project Steps tab in Visual Build Pro 5.7. Now I'm getting an error now that we've upgraded to version 6.2. Maybe this is a regression bug? The only reason I can think we'd need them in project steps is if you specific to ignore failure for a step, but you still want to report that it failed.
-Marc |
#5
|
|||
|
|||
Hmmm, it was always documented and designed that the failed step info be available only from failure steps (if it did work, it was only incidental). What sort of additional reporting are you doing in this situation (if a step does fail but that condition is ignored, the failure information and status is already logged automatically)?
Some options: 1a) If all you're doing is writing extra info to the log, you can do that in the step's vbld_StepDone script event (of the step whose failure would be ignored): Code:
If Step.BuildStatus = vbldStepStatFailed Then Builder.LogMessage "Error building step " & Step.Name ' etc. End If 1b) Centralize this logging in the global vbld_StepDoneProject script event (instead of for each step whose failure is ignored): Code:
If Step.ContinueOnFailure And Step.BuildStatus = vbldStepStatFailed Then ' log failure info End If |
#6
|
|||
|
|||
Thanks for the feedback. We just had the %FAILSTEP_*% macros in the message body of a send e-mail step. I can't remember them returning a value in a long time (if ever), but it didn't cause the build to fail in 5.7, either. At this point we are fine with just removing them from the message body, but it's good to know there is another way to do this.
- Marc |
Thread Tools | |
Display Modes | Rate This Thread |
|
|