HI! I’ve discovere a bug with deadline fails to create publish task if {representation} key is pressent in anatomy data.
@mustafa_jafar mentioned that {representation} key is only for integration step of publish so i thought that for publish task creation this tag is not pressent in instance and actualy it dont need to be here so i just added a empty string to dictinary and it works like a charm!
But i agree with @BigRoy and @iLLiCiT
That fix for now is trash ill do better
Need some info do we need outputdirectory0 env in deadline task? Looks like ayon ignores it at publishing stage because it publishes fine with litteraly brocken path whitch i’ve created using my “fix” i think maybe we can remove this code and this env and it will publish just fine
That is Deadline metadata which allows you to browse the directory directly from the Deadline browser - it’s not crucial. But it’s far from the only entry point that may rely on publishDir not being PER representation as I’ve said before.
I really do think it is not trivial to support this without some massive overhaul. And even then, I think it will make things way more complex. Some file publishes need to remap paths inside an actual exported file without knowing yet where the exact representation lives where it’s reading from. Whether there’s a way to design it wherein that’s trivial to solve I’m not sure. But it’d require a lot of changes, and thorough testing. I wonder if the development time spent on it to make sure all features work is worth it for what it ends up solving on the publish paths themselves.
But I’m sayng representation tag is working in the whole system already peetty good and im using it alredy!) It just falls in deadline and according to you this is not nessary feature at all and we can either delete it or make it for example to select first of representations to have at least some path of many from rops or maybe not throw an exception error of this fails because of representation key because if it can’t solve representation key for deadline browser path and its not anywhere connected to main ayon logic so i’d select to dont have it rather to not be able to publish at all
It will fail in the other cases pointed above to produce ‘predictable’ results. That it works for your “tested” use cases doesn’t mean it won’t break elsewhere. You only happened to by chance find a first ‘bug’.
Whether you’re ok with that in your productions - sure, off yo go.
I’m just saying without all those cases I mentioned solved and safely tested we can’t really support your production scenarios and as you deviate from the main codebase it may become more and more difficult to provide any meaningful response to issues you face - since in some cases it may be hard to debug whether it was due to you have a customized template like this.
Maybe for u its hard to understand me because of my english sorry im trying to say: this fix ive published today is not a fix, this is i see, im talting about do we actualy need to generate this
If it breaks if it meet 【representation 】? This env sound unnecessary for me if it breaks some ayon and dont realy doing anithing only deeadline internal browser)) passed publishing > button “open on disk”
Edited: @mustafa_jafar just showed how to do this easily so now everything is fine))
</{representation}>
using like that makes key optional
Maybe some documentation update?? Ive red it whole sevetal times and this is the first time i hear thst keys can be optional)
