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

PLC WF Dependencies

nipper

OK really strange. Got a overall project with several sites (on several branches) deploy to the same docroot. Share templates and components.

We have noticed some site specific files (.js etc) are being deleted.

When I submit branch1/site1/pagea.page, for some reason it thinks some asset from branch2 js/branch2.js is a dependency. So it deploys that file as well (even though it does not exist on branch 1), and it deletes the object from the prod server, royally **** off everyone who cares about branch2.

Thing is, these objects are not shared, they are branch specific. So branch1 should not even know about branch2.js.

My choices are: turn off deletes for files, keep copies of all js on each branch (and then hope people remember to update all), or see if I can fix it.

So I need to get an idea how does the PLC decide a dependency exists ? If I parse the EA and XML of the page is that sufficient ?

TIA

Andy

Find more posts tagged with

Comments

srosewall

What version are you using?

Pre 7.2 - dependency checking was done using the EA TeamSite/LiveSite/DependentURIs.

Post 7.2 - there's the new dependency checking approach to support GCM, and as yet, I've no idea how that works! Smiley Happy

(personal to do list: find out how the new dependency checker works!)

A side thought - as you are aggregating content on the target from two different locations, you might want to look at OD Concurrency Management - see Admin Guide for details.
"Concurrency management addresses potential conflicts and collisions resulting from simultaneous receipt of like-named files deployed into the same target file location."

Regards,

RonaldV

(personal to do list: find out how the new dependency checker works!)

Personnally I think it is a FFFFFFFFFF*********** disgrace that iwov does not share information like this.

Adam Stoller

Post 7.2 - there's the new dependency checking approach to support GCM, and as yet, I've no idea how that works!
(personal to do list: find out how the new dependency checker works!)

FWIW - I wrote a java class recently (using CSSDK - details posted in another thread) to do dependency checking on .page files for a workflow - and it does generate dependencies for files that are in other branches (like /iwadmin, etc.) if such dependencies exist -- my class explicitly eliminates any files that aren't from the current branch from being attached to my workflow. It sounds like the PLC implementation isn't doing that filtering.

You should be able to verify what's getting returned by using the menu option Actions > Find Related Files

nipper

Thanks. I neglected rev, OS, etc. Linux TS 6.7.2 LS 3.1

I will try find related, though I think that command is 7.1+

I went through the EAs and saw nothing that implies this other file is a dependency as it is not.

Adam Stoller

Thanks. I neglected rev, OS, etc. Linux TS 6.7.2 LS 3.1

I will try find related, though I think that command is 7.1+

I went through the EAs and saw nothing that implies this other file is a dependency as it is not.

pre-7.2.0 - ignore my previous response. That menu option / functionality does not exist until 7.2.0.
I have no idea how LS/SP is determining dependencies prior to 7.2.0 - sorry.

msrinivas

On 7.1 there is an EA on .page files

TeamSite/LiveSite/DependentURIs

GRD

OK really strange. Got a overall project with several sites (on several branches) deploy to the same docroot. Share templates and components.

Hi Andy. I'm not sure it is wise to deploy to the same docroot from multiple branches anyway. If someone creates a site with the same name you'll overwrite the other site.

You may want to separate them into multiple runtimes, and then create additional target nodes and workflows (or add PLC workflow options) to handle the correct target node. Or add an option to deploy to different target paths and then create symlinks on the runtime (unless you are on Windows).

You also could pool the resources in a separate branch so there's only one copy, and use iwproxy rules to access them from the branches in preview.

-Greg

nipper

Hi Andy. I'm not sure it is wise to deploy to the same docroot from multiple branches anyway. If someone creates a site with the same name you'll overwrite the other site.

You may want to separate them into multiple runtimes, and then create additional target nodes and workflows (or add PLC workflow options) to handle the correct target node. Or add an option to deploy to different target paths and then create symlinks on the runtime (unless you are on Windows).

You also could pool the resources in a separate branch so there's only one copy, and use iwproxy rules to access them from the branches in preview.

-Greg

Yea the problem is that this is really 1 big site. It is a major university with departments on various branches. Way too big for a single branch.

I was thinking the proxy setup you described but it will not help my current issue, a page *somehow* decided a file on a second branch is a dependency. It is not an EA.

GRD

I think the cross-branch dependency attachment behavior can be a bug or a feature, however you look at it. In 7.2+ I'm told that the dependency data resides somewhere in the store and is only accessible via CSSDK.

If you deploy to multiple target folders, and then use symlinks to bring them together into one docroot you may be able to better control the overwriting problem.

-Greg

dobrien

Pre-7.2.0, dependencies were maintained as a workarea-relative path in the dependentURI EA. So I'm not at all clear on how you could be getting a depenency from another branch attached. I would recommend to check any custom workflow steps.