This repository was archived by the owner on Sep 20, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 125
Global | Nuke: fixing farm publishing workflow #4623
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
24a22e9
Nuke: fix families mixing up with old way.
jakubjezek001 1e458d6
global and nuke: farm publishing workflow fixes
jakubjezek001 8449c21
Extended Nuke testing classes with representation details
kalisp 4506a2f
Fix broken Nuke local test
kalisp File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come this is needed?
Ideally we should be filtering with families, for example
render.farm, or at least have a comment about why this is needed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is right, new publisher workflow had introduced this requirement. Is there any particular host you know about which is not adding
farmkey into instance.data?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had just agreed with @antirotor @iLLiCiTiT @kalisp that it should be required for all DCC to collect farm key as True in case it needs to be published on a farm.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I believe @tokejepsen tried to ask is why use an
instance.dataattribute instead of adding e.g.farmfamily so that we can explicitly filter the relevant plug-ins to whether it's a farm submission or not instead of always showing the plug-in but then skipping half the instances by comparing the value inside the Plug-ins' process method.So that'd be:
Instead of:
If a particular plug-in still needs to check whether it's marked for farm it could do
"farm" in instance.data["families"]Ah wait, I think I know why. The new publisher can't show instance attribute definitions (like e.g. Deadline Priority, Pool, Chunk Size attributes from e.g. a
SubmitJobToDeadlineplug-in) if the instance itself before the collectors would not already have the "farm" family. So it would disallow showing settings in the publisher UI based on whether it's marked as farm or not.Quite a downside of its design I suppose. Seems like an implementation like pyblish/pyblish-qml#356 with Pre-Collect vs Post-Collect would've solved that. The
farmsetting could then have been detected during pre-collect through plug-ins that are NOT the Creator. Making it much more extendable based on what values are set to on the instance? (The UI would need a refresh after settings influencing pre-collects however).Anyway, likely this change is to workaround that UX design challenge.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding here parallel conversation we had yesterday at discord. This explains a lot and perhaps even addressing @tokejepsen and @BigRoy concerns.
Quoting @iLLiCiTiT from here :
So a pyblish plugin which would care only about render going to farm would still have to do a check of families in process method, which is at the end more complex than simple check for a single key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the issue is with the matching algorithm on Pyblish. Think we can reduce the issue to this test;
Not matter what matching algorithm combination we try here, we will always end up with an assertion error due to missing an exclusion matching algorithm, which might be a good idea to implement in Pyblish?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And how would that solve that the plugin should be executed by combination of
["render", "farm"]? Also there already were ideas how to add that to pyblish and I don' think any were successful.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. Does the above testing code describe the issue we have?
If so we could use it as basis to come up with ideas to solve the filtering problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is where things get interesting - because do we have a use case for this where it's the case?
I'd say the logic should be this:
Collecting does this:
render.render.localis added tofamiliesrender.farmis added tofamilies.From that moment onwards it becomes easier:
render.render.localrender.farmWe can now explicitly target any of the combinations, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that's reasonable for filtering of families but still some plugins must be able to find out if instance will go to farm or not.
Now practicalities. We need to merge this because it is just broken now and we definetely won't do suggested changes it in this PR. Moving the conversation here https://github.com/ynput/OpenPype/discussions/4663 please. We have to also care about cases when there is more than one farm addon + some changes related to Publisher attributes + families cleanup (exactly the conversation here).