nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Deploy and Run

John742

I see how to call external scripts using Deploy and Run depending on whether a defination is successful, but this may be overkill for what I need. With or without using deploy and run how can the success of one defination in an deployment config invoke another defination to run?

Find more posts tagged with

Comments

Adam Stoller

I think you need to read through the documentation a bit more.

You *might* be talking about the nextDeployment element - or you *might* be misunderstanding how deployment configuration files are processed.

It woould also be helpful if yo uinclude version and platform information in follow-up posts.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

John742

open deploy 5.5.1, teamsite 5.5.2, Unix for admin and open api,w indows and unix mix for receiver/base servers.

Actually I have only seen the ability for Nextdeployment to call a config file on a target host. I am trying to call a definition that is defined inside the same config file or to call another config file on the same host.

Adam Stoller

There is no built-in facility for invoking another deployment from the same Base Server.
The only way to do that would be through a DNR script fired on success, on the source side of the deployment.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

John742

in that case can iwodstart be called inside DNR?

Dwayne

Certainly.

The thing you need to be worried about is that you need to make sure you run it with the -inst parameter, to give it a unique instance name if you're going to have the DnR run the same deployment that invoked the DnR. Otherwise it will fail because OD won't allow the same deployment to be running more than once without an -inst parameter to make it unique.

--

Current project: TS 5.5.2/6.1 W2K

John742

Cool!! I have actaully gotten DNR to call and run another config. I am using DNRDeployment on success to invoke the other script, but apprently even if NO files are tranfered (directory comparsion shows no differences) the deployment still returns a success. I need to only call the 2nd config file if actual files are transferred. It seems like Dnrfile - DNR may be the answer, but I have not been able to get it to work. Since it is only avaliable for scipts to be run on the target I have to do a reverse deploy and it is getting kind of messy. Any other suggestions on how to invoke a deployment only when another deployment actually transfers files? Thsnks!!

Adam Stoller

Use the dnrDeployment to run a *script* - that script can check the in-memory log to verify that files were actually deployed before running the next deployment.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

John742

Great!! I will give it a shot and let you know what happens. Thanks for the advice yuo have been a big help!!

John742

Ok I actually have gotten DNRfile to work like it was supposed to. The main problem is the path you give to your script. If the path is wrong and the script is supposed to execute it will hang the whole deployment. The other issue with DNRfile is that it does not support transactional deployments nor does it support running the script on the source side. One way around that is to create a reverse deployment on the target side to do whatever you need. Since I am not using transactional logging and need to know only if actual files of a certain type are sent (not how many, although a regex in the mask param may be able to do this) this has worked for me. I can post the DNR xml piece if anyone wants it. thanks to all

Dwayne

I think that DnRFile is overkill for what you're trying to accomplish. In addition to the problems that you've already pointed out (only on target, non-transactional only) it's a performance killer. You're spawning off a new process for every single file. That's fine if it's truely needed, but I don't think it is in this case.

You can still used the DnrDeployment option. Your script just needs to parse the log data that it receives via STDIN, and look for any files which were actually deployed. That way, you're only running the code once (better performance), it's easy to do on the source machine, and your deployment can still be transactional.

--

Current project: TS 5.5.2/6.1 W2K