deployment-level triggers results ignored

I have a transactional job which runs a macro level script using dnrDeploymentJob before the deployment. If I return from the script, the deployment runs regardless and the deployment shows as completing successfully.

i have had to put in a workaround for this. I set an environment variable in the validation script. then i run a dnr script, executing before the deployment. This script outputs the and the deployment fails as expected.

is there anyway to get the deployment to fail when the deploymenmt-level trigger fails? Or do they act independently of each other? I have attached part of the the script below:

<script async="no" cmd="C:\WINDOWS\system32\cscript.exe C:\scripts\od_prebuild.vbs"/>

<script async="no" cmd="C:\WINDOWS\system32\cscript.exe C:\scripts\od_checkstatus.vbs //NoLogo"/>

<script async="no" cmd="failure script path...."/>

<script async="no" cmd="success script path..."/>

Find more posts tagged with

Comments

Adam Stoller

(reformatted embedded code so that it's readable)

I have a transactional job which runs a macro level script using dnrDeploymentJob before the deployment. If I return <response code="-2" /> from the script, the deployment runs regardless and the deployment shows as completing successfully.

i have had to put in a workaround for this. I set an environment variable in the validation script. then i run a dnr script, executing before the deployment. This script outputs the <response code="-2" /> and the deployment fails as expected.

is there anyway to get the deployment to fail when the deploymenmt-level trigger fails? Or do they act independently of each other? I have attached part of the the script below:

<deployment transactional="yes">
<dnrDeploymentJob location="source" when="before" state="always">
<script async="no" cmd="C:\WINDOWS\system32\cscript.exe C:\scripts\od_prebuild.vbs"/>
</dnrDeploymentJob>

<execDeploymentTask useDefinition="Build">
<deployNRun>
<dnrDeployment location="source" when="before">
<script async="no" cmd="C:\WINDOWS\system32\cscript.exe C:\scripts\od_checkstatus.vbs //NoLogo"/>
</dnrDeployment>
</deployNRun>
</execDeploymentTask>

<dnrDeploymentJob location="source" when="after" state="failure">
<script async="no" cmd="failure script path...."/>
</dnrDeploymentJob>

<dnrDeploymentJob location="source" when="after" state="success">
<script async="no" cmd="success script path..."/>
</dnrDeploymentJob>
</deployment>

Are you sure the output (<response code="-2"/>) is being sent to STDOUT and that it is followed by a newline character?

Can you try with a simple perl script in place of your current cscript?

#!path/to/iwperl
print qq[<response code="-2"/>\n];
exit 0;

specified as:

<script async="no" cmd="path/to/iwperl path/to/perl/script"/>

If the above works - the problem is with the cscript's output. If the above doesn't work it either means you implemented it incorrectly, or you have found a bug that should be reported to Interwoven Support.

PaulW

i replaced the vbscript with calling a perl script to just output the failure response. Deployment still completes woith no failures.

OD admin guide pg 218 there is a table for deployment level triggers. Does this mean the deployment level triggers should never affect whether the deployment is run or not?

Windows 2003 Standard
OpenDeploy 6.1

Adam Stoller

i replaced the vbscript with calling a perl script to just output the failure response. Deployment still completes woith no failures.

OD admin guide pg 218 there is a table for deployment level triggers. Does this mean the deployment level triggers should never affect whether the deployment is run or not?

Windows 2003 Standard
OpenDeploy 6.1

Hmm - interesting - it is behaving exactly as documented. Thinking about it a bit more I'd guess that the code that interprets the the response value doesn't kick in until after the connection is made - which is after the dnrDeploymentJob has run in the "before" case, and happens too late to do the rollback in the "after" case.

The latter I can understand, but the former seems like a gap in which some extra code may be needed to somehow allow a pre-deployment script to abort the deployment before the connection is made. So it isn't so much of a bug as a feature / enhancement request.

PaulW

yeah it seems that way. although, the documentation does refer to returning the -2 response code XML from the deployment-level trigger if it fails. But if everything ignores that repsonse code. whats the point? in case one day this feature is implemented. the doco makes me think something must look at that response.

Adam Stoller

yeah it seems that way. although, the documentation does refer to returning the -2 response code XML from the deployment-level trigger if it fails. But if everything ignores that repsonse code. whats the point? in case one day this feature is implemented. the doco makes me think something must look at that response.

The response of -2 was implemented long before dnrDeploymentJob and trigger-points were implemented - if you look at page 225 of the same manual you'll see which trigger-points for dnrDeployment's are actually processed and it tends to confirm my suspicion that the code for processing it happens at the micro-level not the macro-level (or something like that).

PaulW

Just got a reply from support.

FR#44993:
DNR trigger points outside the connection window should be able to
return error status (e.g., dnrDeploymentJob.) Currently only trigger
points inside the connection window support this.

FR#43224:
Transactional dnrDeploymentJob - If a DNR script returns -2 at the
dnrDeploymentJob-after trigger point, a transactional deployment should
roll back.

Both Feature Requests are deferred at this time.