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

Directory comparison deployments

cute_guy

I am doing a directory comparison deployment feature of the opendeploy to deploy difference between two different branches.

I face a problem like...

When i try to deploy difference between two branches,in which the branches have one file each and the content of the both files are exactly identical, except the version of the files differ.i.e the file in the first branch has version number 3 and the file in the second branch has a version number 1.

So when i do a directory comparison deployment ,even though the contents of the file are exactly identical this file gets deployed.

Is there a way / configuration to check the file gets deployed only when there is change in contents and not based on the version number.

Does the open deploy check only the version of files while doing a deployment?

What exactly does it checks ?

Any help would be greatly appreciated..

Regards,
Ganesh

TS Version 6.5
Opendeploy 6.0.2

Find more posts tagged with

Comments

Adam Stoller

Have you looked at the options you have available for you to use (and the values for those options that are set by default) for comparisonRules ?

I'd suggest reading the manuals and/or looking at IWODHOME/dtd/conf/odsource.dtd

If you're still having problems you'd have to show us a bit more detail about your configuration file (such as what settings, if any, were used for comparisonRules) and a bit more detail about the two files you believe should be treated as identical (/bin/ls -l output, sum output, etc.)

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

cute_guy

Config file :-

<target useReplicationFarm="tgt1" >
<comparisonRules dateDifferent="no" ignoreUser="yes" ignoreGroup="yes" ignoreModes="yes"></comparisonRules>
<permissionRules file="0644"
directory="0755"
user="weblogic"
group="wlsgrp" >
</permissionRules>
<transferRules doDeletes="no"/>

output of ls:-

bash-2.03# ls -l /default/main/branch1/WORKAREA/users/ total 73
-rwxrwxr-x 1 root other 37233 Jul 18 04:41 65animated.gif
bash-2.03# ls -l /default/main/branch2/WORKAREA/users/ total 73
-rwxrwxr-x 1 root other 37233 Jul 18 04:40 65animated.gif
bash-2.03#

Output of iwrlog:-

bash-2.03# iwrlog /default/main/branch1/WORKAREA/users/65animated.gif
file /default/main/branch1/WORKAREA/users/65animated.gif
working revision /main/branch1/1+
----------------------------
name /65animated.gif
revision /main/branch1/1+
last modified Mon Jul 18 04:41:58 2005 by root in area users
size 37233
objid 0x0000100842db958640004964
submit event objid N/A

----------------------------
name /65animated.gif
revision /main/branch1/1
last modified Mon Jul 18 04:41:58 2005 by root in area #8
size 37233
objid 0x000010080003f7350003f72f
submit event objid 0x00002258000000000003f732
Submit
=============================================================================
total revisions: 2
=============================================================================

#######################################################################################################
bash-2.03# iwrlog /default/main/branch2/WORKAREA/users/65animated.gif
file /default/main/branch2/WORKAREA/users/65animated.gif
working revision /main/branch2/5
----------------------------
name /65animated.gif
revision /main/branch2/5
last modified Mon Jul 18 04:40:35 2005 by root in area #27
size 37233
objid 0x0000100842db953340004961
submit event objid 0x00002258000000000003f718
Submit
----------------------------
name /65animated.gif [DELETED]
revision /main/branch2/4
last modified Mon Jul 18 04:40:21 2005 by root in area #26
size 0
objid 0x000010080003f70f0003f70c
submit event objid 0x00002258000000000003f70d
Submit
----------------------------
name /65animated.gif
revision /main/branch2/3
last modified Mon Jul 18 04:39:44 2005 by root in area #25
size 37233
objid 0x000010080003f7080003f703
submit event objid 0x00002258000000000003f706
Submit
=============================================================================
total revisions: 3
=============================================================================
bash-2.03#

Regards,
Ganesh

Adam Stoller

Are you deploying from the workareas? or from the staging areas? (or from editions?)

If you're using staging - then name /65animated.gif
revision /main/branch1/1+
...indicates that you haven't yet submitted that file to staging and therefore you might be getting a real difference between the files.

Also - you might consider turning on checksumCompare="yes" in your comparisonRules - dateDifferent="no" simply means that it will not use *any* date difference (older or newer) as a reason for deploying, but by default if the potential new file is newer than the compared-to "old" file - then it will be subject to deployment.

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

cute_guy

I have tried using checksumCompare....

<comparisonRules dateDifferent="no" checksumCompare="yes" ignoreUser="yes" ignoreGroup="yes" ignoreModes="yes"></comparisonRules>

even then the files gets deployed to the target... i also noticed this error message in src.<deployment>.<definition>.<source>.to.<target>.log

" [ src-is-newer] " What does that mean.....

LIB: 2005-07-19 01:45:04 Options: deploy user=weblogic group=wlsgrp file_perm=0644 dir_perm=0755
ignore_modes ignore_users ignore_groups ignore_acls checksum_compare do_manifest_for_dnr verbose_l
evel=5
LIB: (2) 2005-07-19 01:45:04 [Tue Jul 19 01:45:04 2005] Comparing path[/default/main/branch1/EDITION/ed_0002] with prev path[/default/main/branch2/EDITION/ed_0002]
LIB: (3) 2005-07-19 01:45:04 Walking TeamSite directory[.]
LIB: (4) 2005-07-19 01:45:04 Teamsite 6.5.0 based deployment
LIB: (3) 2005-07-19 01:45:04 Path(./65animated.gif) included.
LIB: (2) 2005-07-19 01:45:04 Comparing done
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 After COMPARE, res=0
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 PRECOMMIT
LIB: 2005-07-19 01:45:04 [Tue Jul 19 01:45:04 2005] DEPLOYING - TeamSite difference to [/u06/depl
oy/web]
LIB: (3) 2005-07-19 01:45:04 Opening directives file[/var/tmp/iwdirEAAasaiA4]
LIB: 2005-07-19 01:45:04 Sending [./65animated.gif] [ src-is-newer]
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 After PRECOMMIT, res=0
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 exiting dotask
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 entering awaiting-commit
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 still waiting for 0
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 exiting awaiting-commit
ENG: 2005-07-19 01:45:04 PDT GMT-07:00 Thread-41 entering commit
LIB: 20

Regards,
Ganesh

Adam Stoller

"[ src-is-newer]" What does that mean.....

First, it's not an error message - it's an information / diagnostic message.

It means, as I suspected but hoped wouldn't be the case, that there doesn't seem to be any way to turn off the default mode of comparison which is if the source [src] file is dated more recently than the target [or dest] file, deploy the file to bring the target file up-to-date.

The default mode can be overridden by some of the other options (e.g. "revert" says only to deploy files if the source is older; "dateDifferent" says to deploy files if the date is different in any way, older or newer; ignore* options allow you to disable certain other methods of comparison).

It looks like you would need to file a feature request for having a ignoreDates option (which would probably only make sense in conjunction with checksumCompare -- either that, or file a bug/feature request that would have the use of checksumCompare overrule the default date comparison logic (I think the additional option might make more sense and certainly would be more flexible)

Out of curiosity - if you run the deployment once (and the file deploy) and then run it again right afterwards - do any files get deployed the second time?

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

cute_guy

if you run the deployment once (and the file deploy) and then run it again right afterwards - do any files get deployed the second time?

Yes, the file is getting deployed ,when i do deployment again for the second time.

Regards,
Ganesh

Adam Stoller

Can you post your entire deployment configuration file?
You may end up having to open up a support case, but in the mean time ...

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

cute_guy

Here is the deployment config file :-

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE map SYSTEM "oddeployment.dtd">
<deploymentConfiguration >
<localNode host="target"/>

<logRules maxBytes="32Mb" level="VERBOSE" />
<replicationFarmSet>
<replicationFarm name="FARM1" >
<nodeRef useNode="tgt">
<targetRules area="/deploy"> </targetRules>
</nodeRef>
</replicationFarm>
</replicationFarmSet>

<definition name="EDITION">
<source>
<iwStore>
<areaDiff area="$area1^" previousArea="$area2^">
<pathSpecification>
<path name='.' />
</pathSpecification>
</areaDiff>
</iwStore>
</source>
<target useReplicationFarm="FARM1" >
<comparisonRules dateDifferent="no" checksumCompare="yes" ignoreUser="yes" ignoreGroup="yes" ignoreModes="yes"></comparisonRules>
<permissionRules file="0644" directory="0755" user="weblogic" group="wlsgrp" > </permissionRules>
<transferRules doDeletes="no"/>
<targetFilesystem area="/deploy" />
</target>
</definition>

<deployment transactional="yes">
<execDeploymentTask useDefinition="$task^">
<deployNRun>
<dnrDeployment when="after" location="source" state="success">
<script cmd="$cmd^"></script>
</dnrDeployment>
</deployNRun>
</execDeploymentTask>
</deployment>

</deploymentConfiguration>

Adam Stoller

Is there more than one definition in this config file (which you're not showing us)? If not, why are you bothering with: <execDeploymentTask useDefinition="$task^">instead of: <execDeploymentTask useDefinition="EDITION">I suggest you get rid of the highlighted line below (unless there's more of this deployment config file you're not showing that makes it necessary?): <nodeRef useNode="tgt">
<targetRules area="/deploy"> </targetRules>
</nodeRef> (which could be simplified to just: <nodeRef useNode="tgt"/>) -- try doing this and see if it helps... If not, can you also show us examples of what you pass in for $area1 and $area2 (exactly what you pass in - no editing for posting purposes).?

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

cute_guy

yes, we have two definition that deploys file to different location, but only one will be invoked at a given point of time,task will have the definition name to invoke.

area1 and area2 will the edition areas, like /default/main/branch1/EDITION/ed_0001 and /default/main/branch2/EDITION/ed_0002

/opt/opendeploy6.0.2/OpenDeployNG/bin/iwodcmd start od.xml -k area1=/default/main/branch1/EDITION/ed_0002 -k area2=/default/main/branch2/EDITION/ed_0002 -k task=QA-EDITION -k task=PROD-EDITION

Adam Stoller

.../iwodcmd start od.xml -k area1=/.../branch1/.../ed_0002 -k area2=/.../branch2/.../ed_0002 -k task=QA-EDITION -k task=PROD-EDITIONTwo things stand out to me in the above:

You don't show quotes being used around the arguments to the '-k' flag (not critical in this case, but generally recommended)
You have two task=... settings in the same command line - which looks like an error to me (or was this just a typo for the post?)

All that aside, have you tried getting rid of the targetRules clause as I previously suggested?

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

cute_guy

Yes, i tried deployment after removing the target rules clause,even then the file gets deployed to the target.

one query if we specify target rules and as well as the target filesystem, i think only former will be considered and latter will be ignored by the opendeploy.is that right?

The command to invoke opendeploy is being run from an external perl file.
- Ganesh

Adam Stoller

If you specify a targetRules section with an area attribute for a node, it should override the targetFilesystem area attribute value for that node - yes.
The fact that the command is being run from a perl script shouldn't make any difference.
Was the fact that you had two task=... statements in the command line shown before a posting error or a scripting error? (it makes no sense to have two settings for the same variable passed in on a single command line).

At this point, however, I'd strongly suggest you open a case with support - because I haven't seen anything yet to explain the behavior you're talking about.

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