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; } } }

Send a filelist file as part of the DNR script call.

sivaramiyer

Greetings fellow TS developers,

I'm in the process of coming up with a solution for the below scenario, any input greatly appreciated.

Consider filelist based OpenDeploy deployment between two different TeamSite servers. I would like to carry out certain operations on the files in the fielist at the target end before performing the deployment.
How do i send the filelist file to the target server over a dnrDeployment script? I checked the manuals : 1. od_71_dev_v01_en and 2. od_71_ref_v01_en, couldn't find anything useful there.

\Best,
Sivaram

Find more posts tagged with

Comments

sivaramiyer

One potential solution I'm looking at is to deploy the filelist itself to the target server as a separate deployment, before this deployment (that calls dnr to process files on the filelist) .

ISCBorisB

One potential solution I'm looking at is to deploy the filelist itself to the target server as a separate deployment, before this deployment (that calls dnr to process files on the filelist) .

DNR Target script automatically receives Deployment Manifest through STDIN, you do not
have to do anything. Manifest is an XML. There are two different stream Formats,
older "log" and newer "manifest". The setting is in odbase.xml:
<dnrProperties allowDnrExecution="yes" infoStreamFormat="[log | manifest]"/>
Default is "manifest".

TS used to provide rudimentary Perl parser, /OD-HOME/solutions/perl/IWXML.pm for the
older "log" Format. I am not aware of any OTB "manifest" format parser. Regardless,
it should be trivial to parse using any XML Parser that you have on target.

sivaramiyer

Thanks Boris! I will try that approach.

Best,
Sivaram

Adam Stoller

Greetings fellow TS developers,

I'm in the process of coming up with a solution for the below scenario, any input greatly appreciated.

Consider filelist based OpenDeploy deployment between two different TeamSite servers. I would like to carry out certain operations on the files in the fielist at the target end before performing the deployment.
How do i send the filelist file to the target server over a dnrDeployment script? I checked the manuals : 1. od_71_dev_v01_en and 2. od_71_ref_v01_en, couldn't find anything useful there.

\Best,
Sivaram

I don't think the manifest from the DNR will work (as per Boris) since you are trying to do this before the deployment - as I don't think there will be any manifest information at that point.

Doing a pre-deployment of the file list is a little clunky but could work if this is a scripted / workflow-originated deployment. Some thoughts regarding this:

ISCBorisB

I don't think the manifest from the DNR will work (as per Boris) since you are trying to do this before the deployment - as I don't think there will be any manifest information at that point.

Ah, yes... Thanks Fish, you are absolutely correct. I've missed the fact that the mode is "before'.

By the same token, if "two scripted deployments" approach is acceptable, Sivaram may for example
run first Deployment with required Conf + dontDo="yes", in "after" mode. That will create a Manifest
and run DNR script without actually changing Files. Second deployment may then proceed without dontDo, etc...

That said, I also agree that we may need more details for any non-trivial advice.

sivaramiyer

Thanks Fish and Boris for your very valuable comments (as always!).

Some background into what I'm trying to do:

I'm putting together a workflow to synchronize multiple TeamSite environments. A user can select the files/folder that needs to be synchronized into the target environment. The files at the target needs to be submitted to STAGING area ( if the file exists ) and an edition of the branch must be created based on STAGING (this is conditional, user selected option from the workflow instantiation).

In order to incorporate the submit to STAGING, logical check to see whether user opted to cut an edition or not and cut an edition (if user opted to do) are all wrapped inside a perl script that gets called as DNR at the target.

Thanks again!
Sivaram

sivaramiyer

i can run "two scripted deployments", 1) do the first one as "dontDo=yes" and run the Dnr in the "after". 2) second deployment will carry out the "real" deployment minus the Dnr.

Adam Stoller

Thanks Fish and Boris for your very valuable comments (as always!).

Some background into what I'm trying to do:

I'm putting together a workflow to synchronize multiple TeamSite environments. A user can select the files/folder that needs to be synchronized into the target environment. The files at the target needs to be submitted to STAGING area ( if the file exists ) and an edition of the branch must be created based on STAGING (this is conditional, user selected option from the workflow instantiation).

In order to incorporate the submit to STAGING, logical check to see whether user opted to cut an edition or not and cut an edition (if user opted to do) are all wrapped inside a perl script that gets called as DNR at the target.

Thanks again!
Sivaram

Generally, if you're talking about code and configuration updates from a DEV TeamSite server to a PROD TeamSite server (perhaps with another environment (or more?) in between - the "standard" protocol is that no changes should ever take place anywhere except for DEV (except when doing environment-specific bug-fixing, but those changes should be folded into the DEV code manually as soon as the fixes are confirmed).

Following that route, there should never be anything in the "upper" environments that need to be submitted before the propagation of changes from the lower environment - instead you would have a DNR that runs on the target side after the deployment, which could make use of the manifest info from STDIN, to take care of submitting the files and publishing an edition on the target system.

However, you seem to be happy with the two-deployment approach ... so hopefully it will do what you want.

sivaramiyer

Hello,

The workflow that i was working on is used to synchronize content from production into the lower ( TEST and DEV ) environments. The flow of content in the other direction (DEV -> PROD or TEST -> PROD) is not a valid use case.

Business wanted the content in the lower environment to be version-ed before getting replaced by the content from PROD.

I got this functionality working through a kludgy solution, not through a two-step deployment mechanism. Solution below -

<script cmd="/iwperl

and at the DNR script's end:
1. Get the list of files from STDIN.
2. Write the list of files into a tmp filelist (on target) with jobid appended to the name of the filelist.
3. apply custom processing (submit files , cut an edition of the branch )
4. check for the existence of the above tmp file during the subsequent dnrFile calls, if the tmp file exists, skip the dnr execution, end)

not a great way of getting this done, but, I couldn't find (nor i had enough time to research) on how to run a) dnr at the target end b) before deployment c) on the list of files in the filelist.

Thanks!
Sivaram

Thanks!
Sivaram

sivaramiyer

Step 1: Deployment definition -
instead of dnrDeployment Or dnrDeploymentJob, I used "dnrFile" inside the OpenDeploy deployment definition.

Step 2: In the DNR script -
1. Get the list of files from STDIN.
2. Write the list of files into a tmp filelist (on target) with jobid appended to the name of the filelist.
3. apply custom processing (submit files , cut an edition of the branch )
4. check for the existence of the above tmp file during the subsequent dnrFile calls, if the tmp file exists, skip the dnr execution, end)

not a great way of getting this done, but, I couldn't find (nor i had enough time to research) on how to run a) dnr at the target end b) before deployment c) on the list of files in the filelist.

Thanks!
Sivaram