Hi! do we have opportunity to lauch scripts on application start to make auto status change? (I need it with Kitsu and I believe for kitsu we dont have it yet so maybe I’ll implement this but i dont know where to put this scripts)
Hello,
As far as I know, the closest thing to your description launch scripts on application
matches two things we support:
- Hooks: are plugins that run in terminal before the application launch, they can set environment variables and such. e.g. pre_ocio_hook.py in ayon-core.
You can add one general hook to ayon-kitsu if that fits your needs. - Modify
Host.install
method e.g. HoudiniHost.install- Call what ever function you want at the end of it.
- Add a callback/modify a callback function.
You can still use the regular callbacks supported by the applications e.g. Maya and Houdini.
Could you tell us more about what you are trying to achieve ?
This looks like what i’m searching! I’ll try to make this fuction and commit
@mustafa_jafar tell me please does hooks work with dev budles from disk?
do i have opportunity to check if my hook is in order?
and
do i need to hard code apps inside kistu hook to start it?
do i need to make some poetry to make kitsu hook launch?
I’m asking because for now i have no soccess to even start hoot on app start
EDITED nevermind solved it
yoyoyoyo
@mustafa_jafar the next thing! Is there a way like hooks but after application close?
I want to implement status check if there was no publish so WFA status was not posted to change status from wip to something else
As far as I know, that should be a callback inside your DCC.
I’m not sure if we currently have a list of available callbacks.
In my opinion I think this is overcomplicating the workflow.
As I’ve mentioned on your PR, Currently we have integrate-kitsu-note that only changes the status at publishing.
Could you share your experience using this plugin ?
My experience so far is good exept some things whitch is not working out of the box and need some wiggling to make it work (houdini previews for example) but its ok.
I just have to work with a lot off newcomers to my pipeline thats why i prefer to automate everything that can be automated like in this case: status changing when artists lauch an app.
Previously i was using Cerebro and treirs tentaculo and similar behavior was here and it was comfortable (I’d like to say that only start was bettter because of status change everything else was not as good as we have here in Ayon ehehe)
So for me its pretty straightforward that artist opens an app do some work publish it and that’s it. Cases when i or artist launch a workfile wo publishing a work for me is soooo rare so i dont see why not to automate it
yeah, that’s what I was referring to…
Why do we have to change the status when the app starts if it’s going to be updated automatically when we publish by the Integrate Kitsu Note
plugin?
ehm,… Maybe, Would you prefer to update the status as soon as the artist begins working, considering there might be a delay between starting the project and the first publication?
I just want to know what each artist do right now. In my case when a lot of things can change on the fly I always need to have the latest info about artists work even if they just started a task to make important decisions.
But after some sleep i think partially you’re right so il’ll try to make all this logic optional as Integrate Kitsu Note
so each admin can deside use it or not
Let’s summon @Danell
So, Integrate Kitsu Note
has some caveat that there might be a delay between the app launch and the first publish. which doesn’t reflect the actual status of the task for admins. this can be a problem with newcomers how may have more delay than usual.
and, If I got @timsergeeff correctly, then this was the motivation behind his PR Now when we start task from AYON we see WIP status in Kitsu by timsergeeff · Pull Request #70 · ynput/ayon-kitsu · GitHub
Could you tell us what do you think ?
poff I’m here!
Sounds like a good idea but I have some points about it. I’ll post it over on the github PR
@Danell @mustafa_jafar
here it is!
let’s discuss since i’m not confident if my code is good enought to yor standarts, but everything works, has nessesary switches and debug logs
Now we have ability to change status on users starting app action.
Pause other tasks with WIP status
We can turn off pausing all other WIP tasks. This logic made of state: only one task can be WIP at a time.
Farm render status change
Previosly task was getting status change (WFA) only at publishing state in deadline so in between of publishing job to farm and publishing to kitsu we have nothing indicating current task status. Now we have FARM status change when farm rendering is on
Additional info
The settings allow to configure status change conditions so statuses will not double. And some other changes to settings needed to be done to make all logic work and ahve opportunity to swith in on or off
Testing notes:
- Add nessesary statuses to your kitsu production
- configure status changes in addon
- mark some statuses in kitsu as WIP (only for test)
- start other task
- see all other tasks now was PAUSED
- publish a job on farm
- see status change to FARM status
Thank you for your contribution.
Let’s move the discussion to GH.
@mustafa_jafar @BigRoy I’d like to make some changes and need some help:
1)This waning bothers me
@BigRoy was mentioning that i can remove this path here but will hook work?
I think if i remove that the plugin will not know where to find hook file
this part of a code dont work as it should
this part is for farm status change and it works now if review family dont met but sometimes (for example in case i publish for example a texture to task) script will post farm status because i dont set it to review.
When i was debuging i saw this falilies
DEBUG: [‘render’, ‘render.farm’, ‘kitsu’, ‘workfile’]
for nuke farm
DEBUG: [‘hda’, ‘redshift_rop’, ‘workfile’]
for houdini farm
DEBUG: [‘hda’, ‘redshift_rop’, ‘workfile’, ‘ftrack’, ‘review’, ‘render.local.hou’, ‘render’, ‘kitsu’]
for local houdini with review
so when i do farm rendering there is no review that’s why i went with this incorrect aproach
soo is what key in data of instance will determine is an instance will go to farm?
it’s hard for me to tell because I didn’t check the full discussion on the PR.
I don’t think we use a consistent names for farm families across different addons.
However, you may use farm
key in the instance.data
if instance.data.get("farm"):
# do something.
@mustafa_jafar @BigRoy @Danell hi guys!
i’ve updated my feature to resolve a bug when erroneous status was published so logic now works good but i have some issues with tests mostly because my lines is too long
could you please help with this?
or should i maybe forget about merging my featute and just use only as my own fork for only my prod because we dont have further discussions about this features?
Hello,
So, your PR adds the following features:
- change status when user launches an app.
- only one task can be wip. the rest will be paused.
- when submitting to farm, set the status to farm.
The first one makes sense (although in the current status the task will change when the artist makes any publish)
I think 2. and 3. are specific for your studio.
e.g.
- for 2. some studios may allow working on more than one task simultaneously.
- for 3. I don’t have
farm
status by default.
I’m only adding food for though, and I could be wrong.
anyways, I’ll test your PR when possible.
Farm status is custom and i have options to put any status on farm render in settings
For pause maybe im wrong but i think its physicaly not possible to do 2 things at one moment of a time. By the way all this fuctions you can turn on and off in settings
I am more intrested in fault tests with “line too long” error. I dont understand the ways around it