Hello,
I was wondering if there is a way to keep the ID number of a toolkit app if it has been edited and re-uploaded. I’ve noticed that any changes I make require an update to all the yaml calls for ID and if possible I’d like to keep them the same.
Thank you,
Interesting problem. As the ID is a file id, I think you’re out of luck on this one.
Maybe a git descriptor would be a better fit? Although that comes with it’s own set off issues.
Ya we’ve tried the git descriptor and ran into some issues when it came to pulling the repo correctly, due to the repo being set to private and have kinda opted to just upload a zip file.
yup, the other option is to host the repo locally, but then you may have issues if your studio is multi-platform (I don’t think git descriptors support os specific paths).
Hi all – Patrick’s right that this is not supported: the idea is that a descriptor should be immutable (though you could argue that you can change out files in a path or dev descriptor, so that argument doesn’t totally hold water).
We’ve talked about it internally before, but we’ve never gone so far as to change functionality. But I can see your point, especially if you were using your uploaded app in multiple projects. If it’s something you feel strongly about, I encourage you to put in a feature request.
Having said that, you shouldn’t have to make this change in more than one place in your config. The Toolkit environment configuration files (config/env/*) support includes – a way for you to define a setting in a single location, then reference it into every place it’s used. We do this in the Default Config – the location descriptor for apps is defined in config/env/includes/app_locations.yml, and included into every engine file that needs it. If you follow this convention, you should only need to set that version value in one place in your config. You can learn more about includes in our Environment Configuration Reference.
Also is there a tool to manage clean up of these downloaded toolkits. I’ve been noticing that with every update it downloads an entire library in a new file these seem to build up and become very confusing.
You know what?.. given the “immutable” horse has bolted, what might be really cool is another descriptor type, maybe called “descriptor-ref” which would allow you to point to another descriptor defined on the SG database in a field, on a text entity.
eg:
you have a new custom text field on the pipeline-config entity called “my-app-release”. In this field, you put the descriptor pointing to the latest release of your tool (just as you currently do in the env yamls)
The descriptor in your pipeline config for the app location might take the form :
{
type: descriptor-ref,
entity_type: PipelineConfiguration, # entity type
field: my-app-release, # attachment field where payload can be found
# entity_id : 123 # … in this example, it would default to the pipeline config entity this setting lives in; eg a parent - child relationship. If you wanted to set the studio config in another entity then you’d supply the specific id here. Perhaps an odd use-case.
}
and then the text you enter in the my-app-release field on your pipeline configuration entity would be a normal descriptor pointing to the specific release :- eg
sgtk:descriptor:shotgun?entity_type=toolkit_bundle&id=111&field=uploaded_file&version=222
The result being you could have a shared pipeline config used by multiple projects, but you would still be able to version-up/set-version on a per-pipeline config (entity) or per-project basis, if you so wanted. It would solve the OPs issue as their config would point to a single entity field, that could then be update to point to any specific uploaded file as required.
Theres an obvious health warning about storing configuration data in the database… but given we pretty much do this anyway with descriptor based pipeline configs, it feels like this old rule of thumb is more of a moot point… is it not? Configuring app versions would be much easier via the spreadsheet gui of the website than having to fork configs, edit text files, etc. Pipeline Configuration entity Descriptors are such an awesome way to configure the location of actual pipeline configs, it’s a shame the same approach isn’t yet available for confiuguring the apps the config uses.
Discuss! 
