Pre-register publish version

Nik · October 2, 2020, 6:29pm

Hi, I’m designing an automated pipeline and need to know if it’s possible to pre-register/reserve a publish version up front (so as to be able to determine up front the version/path location for each task in the line up). Is that possible via tk-multi-publish2?

Beth · October 2, 2020, 11:31pm

Hi @Nik,

Thank you for your question - I will pass this along to our Toolkit team for a response on Monday. Our team is down a few due to a company holiday today.

Cheers,
Beth

philip.scadding · October 6, 2020, 11:57am

Hi @Nik when you say up front, how up front do you mean? Do you mean when the publish items are collected?
If so, and you’re using the default publish plugins, or they are derived from ours, then if you define the version on the item’s properties, then it should use that:

item.properties["publish_version"] = 5

github.com

shotgunsoftware/tk-multi-publish2/blob/f170369a01c4ef6a6bc89eeadca19d0c9b1cfa57/hooks/publish_file.py#L608


Get the publish version for the supplied settings and item.

:param settings: This plugin instance's configured settings
:param item: The item to determine the publish version for

Extracts the publish version via the configured work template if
possible. Will fall back to using the path info hook.
"""

# publish version explicitly set or defined on the item
publish_version = item.get_property("publish_version")
if publish_version:
    return publish_version

# fall back to the template/path_info logic
publisher = self.parent
path = item.properties.path

work_template = item.properties.get("work_template")
work_fields = None
publish_version = None

tannaz · October 7, 2020, 1:24am

Hi @Nik –

I talked this over with Phil this morning, and we thought it’d be useful to dig a little deeper.

First off, can you tell us more about what you’re trying to achieve? What would this “reservation” be a protection against? What is the goal here? And when you say “up front”, where in the workflow are you referring to? At collection time, when the user has opened the Publisher and it’s displayed the available publish items?

If your goal is just to know what the file path is going to look like, you should be to use the Toolkit API to get that from the templates and existing files. Take a look at this document, specifically part 6, to learn more about that.

Having said that, it’s worth noting that even with Phil’s suggestion above, there’s no real “reservation” going on – it’s just predetermining what the version number will be before the actual register_publish() call creates the Publish in Shotgun. So, there is a chance that another user would publish to that same version number in the interim (although that chance is slim – it’s rare that multiple users would be working on the same publish item).

To protect against that race condition, you could create a placeholder PublishedFile entity at “up front” time, then update it with the full data set at publish time. This can be error-prone though - what happens if the app crashes? Are you left with all these orphan placeholders in your PublishedFile table? When do you clean those up? etc…

So, if you can let us know a little more about what your goals are here, hopefully we can lead you to good solution.

Nik · October 20, 2020, 4:42pm

Hi @tannaz

Sorry I just saw this message. So I was actually overthinking it. I needed a way to protect against the race condition so that if I were running a command that kicked off a queue of publishes from multiple DCCs, each process/job in the queue would need the publish id from the previous job in the queue so I would want to have all that information before kicking off the queue. After seeing Phil’s comments though, I realized I just needed to create the publish entry in shotgun then update it with whatever info is missing after the job completes (and make sure it’s actually updated which is much easier to do).