Enhancement: Add version number to GlobalJobPreload and validate it

[kalisp]

Is there an existing issue for this?

• I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?

There is no way how to know that GlobalJobPreload (or any DL plugin) needs to be redeployed because of change.

This might potentially lead to unnecessary errors because content of DL repo is outdated.

How would you imagine the implementation of the feature?

New version.py should be created in OP_REPO/modules/deadline/repository (to have more granular multiple version.py per plugin AND GlobalJobPreload seems overkill),

This value should be passed to publish job as a environment variable (`OPENPYPE_DL_REPO_VERSION) and new validator should be created to compare value from local file against it. (In similar fashion as PS does.).

Adding this as env var seems to be simplest as adding it to extractenvironment would result in change of cli signature. We already have some logic triggered for publish job currently, so it could be added there.

Are there any labels you wish to add?

• I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:

No response

Additional context:

No response

[cuID:OP-7414]

[BigRoy]

Actually I think the version should at least be in GlobalJobPreLoad (or a checksum of itself?) because what is usually the cases is that a studio forgets to update that particular script but did update OpenPype, the server, etc. giving all sorts of strange issues.

Or... the GlobalJobPreLoad could maybe report if it differs from the GlobalJobPreLoad.py in the current running OpenPype version just to hint at that being a possibility - this would avoid the need for storing versions in the files but would just check against current OpenPype?

[kalisp]

I was thinking about hash and different versions per items in that folder, but I think we should make it simple and take it as one big element. We are saying in readme copy the whole hierarchy to Deadline so it could be a good assumptions that people are just chucking everything there.
(So we are not checking "is my GlobalPreload or Ayon plugin or Openpype plugin obsolete", but "are all OP plugins up to date".)

There will be hassle enough with bumping up a version.py file to add there separate versions, hashes etc for more granularity.

And I am not sure if simple warning is enough, I would trigger failure. This way someone will need to take a painful moment and solve it, but it limits it will maybe run maybe not for a couple of weeks/months.

[BigRoy]

And I am not sure if simple warning is enough, I would trigger failure. This way someone will need to take a painful moment and solve it, but it limits it will maybe run maybe not for a couple of weeks/months.

How do we really detect if it's invalid?

Also, note - we are using a customized GlobalJobPreLoad ourselves (and for most fixes there isn't a crucial need to make sure you're on the latest deadline plug-in).

I'd make it a warning just because of that - it's totally fine to differentiate in version, but if errors occur with your renders the information is useful for debugging.