Update kitsu task status when launching an app

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:

  1. 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.
  2. 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 :magic_wand:
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 ?

1 Like

poff I’m here! :sunglasses:

Sounds like a good idea but I have some points about it. I’ll post it over on the github PR :slight_smile:

2 Likes

@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.

1-ezgif com-video-to-gif-converter

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.

2-ezgif com-video-to-gif-converter

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

3-ezgif com-video-to-gif-converter

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
image

Testing notes:

  1. Add nessesary statuses to your kitsu production
  2. configure status changes in addon
  3. mark some statuses in kitsu as WIP (only for test)
  4. start other task
  5. see all other tasks now was PAUSED
  6. publish a job on farm
  7. see status change to FARM status

Thank you for your contribution.
Let’s move the discussion to GH.

1 Like

@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.