Skip to content

Set version tags on publish#1850

Open
MustafaJafar wants to merge 27 commits into
developfrom
enhancement/1673-yn-0458-set-version-tags-on-publish
Open

Set version tags on publish#1850
MustafaJafar wants to merge 27 commits into
developfrom
enhancement/1673-yn-0458-set-version-tags-on-publish

Conversation

@MustafaJafar

Copy link
Copy Markdown
Member

Changelog Description

  • Add Tags Enum to integrator, it fetches the tags list from the project anatomy.
  • Add tags to version entity on integrator and hero integrator
image

Testing notes:

  1. Set tags in publisher
  2. Publish

@MustafaJafar MustafaJafar requested review from BigRoy and iLLiCiTiT May 20, 2026 16:45
@MustafaJafar MustafaJafar self-assigned this May 20, 2026
@MustafaJafar MustafaJafar added the type: enhancement Improvement of existing functionality or minor addition label May 20, 2026
@ynbot ynbot added the size/XS label May 20, 2026
@BigRoy

BigRoy commented May 20, 2026

Copy link
Copy Markdown
Member

Can we move the version tags setting of values into a separate plug-in, that can also be disabled, similar to @moonyuet 's work here: #1847

@BigRoy BigRoy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As stated above:

  • make sure it's a separate plug-in

But also:

  • make sure it can be disabled in settings
  • have it disabled by default so the attribute does not show in publisher UI.
  • if tags are already in versionData when it reaches this plug-in with the attribute def, then append the selected tags

The only change in integrator should be that it'd be able to take this data from instance.data and apply it to the version.

Later we may want to add profiles for defaults, but I don't think we should now. Because it'll open a can of worms of what may need to be adjustable (like which tags you might be allowed to select from per context and whatnot)

@MustafaJafar MustafaJafar linked an issue May 21, 2026 that may be closed by this pull request
@MustafaJafar MustafaJafar requested a review from BigRoy May 21, 2026 13:46
@MustafaJafar

MustafaJafar commented May 21, 2026

Copy link
Copy Markdown
Member Author

The only change in integrator should be that it'd be able to take this data from instance.data and apply it to the version.

I'm currently depending on instance.data["versionData"]["tags"]
I'm now checking relying on instance.data["tags"].

edit: I checked tags in instance data, I only found we add them below representations. so dedicating the instance data tags for versions seems fine.

Comment thread client/ayon_core/plugins/publish/integrate_hero_version.py Outdated
@ynbot ynbot moved this to Review In Progress in PR reviewing May 21, 2026
@github-project-automation github-project-automation Bot moved this from Review In Progress to Change Requested in PR reviewing May 21, 2026
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py Outdated
@ynbot ynbot moved this from Change Requested to Review In Progress in PR reviewing May 21, 2026
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py
Comment thread client/ayon_core/plugins/publish/integrate_hero_version.py Outdated
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py Outdated

@BigRoy BigRoy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work as intended.

@github-project-automation github-project-automation Bot moved this from Review In Progress to Merge Requested in PR reviewing May 21, 2026

@BigRoy BigRoy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some convert to set nodes.

Comment thread client/ayon_core/plugins/publish/collect_version_tags.py Outdated
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py Outdated
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py
@MustafaJafar MustafaJafar requested a review from iLLiCiTiT May 22, 2026 10:46
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py Outdated
Comment thread client/ayon_core/plugins/publish/integrate_hero_version.py Outdated
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py
@MustafaJafar MustafaJafar requested a review from iLLiCiTiT May 26, 2026 16:13
@MustafaJafar

Copy link
Copy Markdown
Member Author

@iLLiCiTiT Thank you. let me know if there are further actions.

@BigRoy it's worth mentioning that the enum disappears if the project has no tags. is this the desired UX?

@BigRoy BigRoy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - didn't test again though.
Just one cosmetic change to the logged message.

Comment thread client/ayon_core/plugins/publish/integrate.py Outdated
Comment thread client/ayon_core/plugins/publish/integrate.py Outdated
@github-project-automation github-project-automation Bot moved this from Review In Progress to Merge Requested in PR reviewing May 26, 2026
@ynbot ynbot moved this from Merge Requested to Review In Progress in PR reviewing May 26, 2026
Comment thread client/ayon_core/plugins/publish/collect_version_tags.py Outdated
Comment thread client/ayon_core/plugins/publish/integrate.py Outdated
)
# Error if not all are string.
if not all(isinstance(tag, str) for tag in tags):
raise PublishError(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
raise PublishError(
raise KnownPublishError(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this recommendation wrong @iLLiCiTiT

seeing that KnownPublishError is 'deprecated', see:

class KnownPublishError(Exception):
"""Publishing crashed because of known error.
Artist can't affect source of the error.
Deprecated:
Please use `PublishError` instead. Marked as deprecated 24/09/02.
"""

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iLLiCiTiT just checking?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I think that deprecation should be removed. Sometimes it makes sense to raise an error that doesn't have to have "user-friendly" message and title.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you give some example on how to use that one differently from PublishError?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I'm wrong, it just shows the message of the expcetion. In that case we don't have a way how to show generic user error message with PublishError.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather have more errors that are more descriptive, than less. So we should really be recommending KnownPublishError if that's the only one actually showing anything remotely useful to the user. I think always if we raise a dedicated error, even if obscure. Anything is better than "Not your fault" message - it's one of the bigger complaints I've been hearing over time. The not your fault message telling you nothing.

Anyway, let's make sure it's the one that is more descriptive to the user - and if that is KnownPublishError then use that. And also make sure it's not marked deprecated anymore.

@iLLiCiTiT iLLiCiTiT Jul 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

KnownPublishError does what PublishError does by default.

The thing is that sometimes you want to write technical information for a dev to the message which probably should not be shown to an artist.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is that sometimes you want to write technical information for a dev to the message which probably should not be shown to an artist.

I see - so both show the message, but one (which one?) allows to attach additional messages that are shown elsewhere? if so, where?

@iLLiCiTiT iLLiCiTiT Jul 3, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see - so both show the message, but one (which one?) allows to attach additional messages that are shown elsewhere? if so, where?

No, I thought that KnownPublishError does not show the message to artist -> so you could write more technical information there, but I was wrong.

The point is PublishError should be used (because it does what KnownPublishError does) and KnownPublishErro is really deprecated. To add more information to the error we would have to modify pyblish, or publish report viewer.

Comment thread client/ayon_core/plugins/publish/integrate_hero_version.py Outdated
@BigRoy

BigRoy commented Jun 17, 2026

Copy link
Copy Markdown
Member

@MustafaJafar would be great if you can finish above comments 🙇‍♂️

@MustafaJafar

Copy link
Copy Markdown
Member Author

@BigRoy I pushed changes and gave it another test run on my end and it worked.

@MustafaJafar MustafaJafar requested a review from iLLiCiTiT June 17, 2026 16:13
Comment thread client/ayon_core/plugins/publish/integrate.py Outdated
Co-authored-by: Jakub Trllo <43494761+iLLiCiTiT@users.noreply.github.com>
if tags is not None:
# Check if tags is an iteratable.
if not isinstance(tags, (list, tuple, set)):
raise KnownPublishError(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
raise KnownPublishError(
raise PublishError(

)
# Error if not all are string.
if not all(isinstance(tag, str) for tag in tags):
raise KnownPublishError(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
raise KnownPublishError(
raise PublishError(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/XS type: enhancement Improvement of existing functionality or minor addition

Projects

Status: Review In Progress

Development

Successfully merging this pull request may close these issues.

YN-0458: Set version tags on publish

5 participants