Publishing only against Tasks

Imagine only publishing against task contexts.

Much of the config is entity then entity_step

If one were only publishing and versioning against tasks could much of the config related to entity be omitted in favor of always (and only) configuring for entity_step?

Thank you


Hi @Rhea_Fischer,

The Shot and Asset env’s are a little “vestigial” compared to the shot_step and asset_step environments, you could probably remove them and not have any issues, as by default there are not any settings for publishing in a shot or asset env.

I would leave Project and Sequence in there thou, things like NukeStudio like them among others.

Is it just a less cluttered config you are after?

1 Like

Hi @DavidMason,

Sure, you’ve got the idea; less cluttered.

Overall there’s a large amount of necessary repetition in the SGTK config files. But its a bit hard to tell whether that is structural vs exemplary, i.e. we really need some things defined on this entity, versus here’s a friendly placeholder for you. IOW the SGTK configuration is a bit fussy to setup.

Part of the inspiration for the question came from a plugin the Head of Engineering at Fox VFX Lab (Alejandro Arango) configured. It was a great example of minimizing what one needs to bother with.

Your casual reply seems a good confirmation :slight_smile:



So I would say that the config is set up to serve the use cases we most commonly see, and to work with all supported software that we provide integrations for.
So most studio’s work with assets and shots so it makes sense to cover those. However, you don’t need those if you don’t want them.

The environment you will probably always want is project.yml especially if you are using Shotgun Desktop as this always works in a project context.
You will need site.yml if you are using the config as a site config, i.e a PipelineConfiguration without a Project set.

Other than that it’s up to you what you want to keep or lose. For the most part though we’ve tried to keep the config as sparse as possible, for example, we only define the settings in the environment ymls that need to be set, and leave off anywhere the bundle’s default setting can be used.