Iterative tasks

Hello all, wanted to ask what is the recommended approach here. Let’s say we have a series of tasks in a pipeline e.g Task A, then we go to Task B etc. If task E requires changes back in Task A and then again having the product to go through each task again to reach task E, what is the recommended approach when it comes to task statuses and versioning? Eg if we have the following task statuses
New/In Progress/Ready for Review/Approved/Fixes required/Blocked. Should we mark again all upwards tasks as open when a product requires iterations?

I am asking because we have a linear flow of tasks but a task may require changes and us needing to go back through all previous tasks again to fix the issue. So need to distinguish between changes required within a task itself and changes that require revisiting earlier pipeline tasks.

2 Likes

Hello and welcome!

It really depends on what you are actually doing in those tasks and on the level of the automation required. For example, pretty common scenario is:

  1. Modeling: modeler publishes a version v001, It is approved in the review, so his task is marked as complete
  2. Rigging: rigger takes this model and uses it in a rig, he publishes this rig and again, it is approved and the task is marked as complete
  3. Animation: poor animator tries to do his job but he finds out that the character model is missing a leg, so he pings his lead and the modeling task is set to fixes required and modeler is notified.

Now at this point there are several options that are more or less workflow specific:

In some cases, you can completely automate the whole process - for example lookdev changed and with the new approved version you can trigger automation that will take all following tasks, update that lookdev in the workfiles, auto-publish new versions and at the end it will mark the finished renders on farm with status ready for review, all of it without any human touch.
This can be done in certain cases but in some - like the example with animation, you need some work or at least check from the rigger that the model change didn’t break anything.

You can also automate status changes and use heavily the linking system in AYON for that. Unfortunately there is not much documentation on that yet, but essentially you can use pre-defined types of links linking different entities or even define your own. By default, there are generative (linking version to version), breakdown (lining folder to folder), reference (version to version) and template.

Links are created whenever you publish something, for example between the version of the workfile that was used and the published version of an alembic cache produced from it.

With the links, you can establish hierarchy between tasks and based on that you can automate status changes and so on.

AYON doesn’t have this by default yet as there are as many opinions about it as there are studios in the world :slight_smile: but good news is that this year we have automations on our roadmap so there are some goodies on their way!

If you have any questions about how to use the links or how to run the automations, feel free to ask!

and btw this is the “side effect” of having the links: AYON Node Graph addon - Ynput

4 Likes

Thanks for the quick reply! Yes I actually noticed the linking feature and wanted to know more about it but as you mentioned there is not too much documentation but sounds like it’s exactly what we need to use. Is there ETA on when to expect some more documentation or examples on how to use those? We mainly use the REST API of AYON and noticed the “Links” section but would be great to see some simple examples.

2 Likes

No ETA, sorry :slight_smile: But! Working with links is very easy. Each project has it’s own link type defined in the Anatomy Settings here ayon+anatomy+preset://_/link_types (this is preset, but the same thing you’ll find for every project).

You can notice that there are several link types with their input type, output type and visual settings. So with REST API you need to provide this for creation:

{
"input": "string",
"output": "string",
"name": "string",
"link": "reference|folder|version",
"linkType": "reference|folder|version", 
"data": { }
}

where input and output are entity IDs of the stuff you want to link together with the linkType defined on the project. You can name your link and you can provide optional data.

So you can create for example new type of link called taskFlow that has input type and ouput type set to task and then you can have something listening to events setting this link on task creation (or whenever based on your setting) - ideally you can create your own addon with the setting frontend and the service processing the events and creating task links / automating status changes - and then open source it :smiley:

You can have settings controling what task type should follow what task type, then the service that will go over task creation events and creating all the links if they are not yet set. After that you can create for example integrator plugin that will check those links on publish and trigger the status change, or you can do it via the service, depends on your need and the context data you need to have available.

Advantage of using links is in that it is more “static” than events and you can analyze, visualize them later, etc.

here is example how we work with them on python api level: ayon-core/client/ayon_core/plugins/publish/integrate_inputlinks.py at 283465bbb76d12b0224ef4936e7adc11698618a4 · ynput/ayon-core · GitHub

Sorry about the missing documentation - we definitely want to add it plus we’d like to use links much more in the pipeline. I think it is very powerful and versatile concept that can be at the end used from the core pipeline functionality to production tracking features.

2 Likes