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?
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.
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
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.
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).