Yes that’s right.
I’m looking to be able to have a single pipeline configuration for the entire studio, but where the studio defaults need adjusted on a per-project basis, instead of having a seperate pipeline config, I would impliment overrides in files within the project folder. I appreciate that this aim is perhaps counter to the design philosophy of SG, but I think it’s a goal worth investigating.
For example, most projects are identical in requirements. One area that definitely does change per-project is naming convention for client delivery of media. In this case, one might override the default template for client deliveries. I would do this by including a project_templates.yml that redefines a single template. I think this would be a pretty powerful pattern.
As it is, we can do this for hooks (eg for changing the format of reviewsubmission transcodes per project by pointing the hook to the project based hook using an env var in the template path), but being able to actually override templates in the same manner is not currently possible.
I’m attempting do this with a hardcoded “include” in the pipeline config templates.yml, but I imagine another approach might be for SG to add a hook which could be used to intercept template resolution. This is a feature when templates are defined in app configs, but this, as far as I can see, is not applicable to api calls to templates; eg tk.templates[‘some_template’]
As I say, this is fairly anti-pattern behaviour and carries certain risks (eg where a template no longer matches the schema) but the benefits of having a truly studio-wide config that can be selectively adapted on a per-project basis are clear; maintanance overheads spiral out of control where you end up with a custom pipeline config per-project would be avoided.