Tank Command for Dev config

I’m currently looking to create an app which will run in tk-shell to manage uploading new versions of our sgtk config to shotgun (we want to use distributed configs). I know that in the centralised configs it creates a tank command that I could then use to launch the command (e.g. tank my_release_command). How would I go about doing this from a dev config locally?

I have the config in a git repo that I’ve pulled down and ideally I’d like to cd into the directory and run something like tank release. This would bootstrap that config into the site.yml env and run my release command. At the moment I’ve done it with a script that bootstraps tk-shell engine (similar to the example on the Distributed Config and Render Farm Setup). And then I can run my command from there. This works but it’s not very neat because then when I write another command I have to write another bootstrap to be able to run it. The tank command is handy as it will expose all the commands available. I could copy the code from the tank_cmd.py to have the logic for finding all the commands available on the current environment. I’ve also noticed that the tank_cmd.py takes a config path so maybe I could bootstap with a script and then pass the bootstrapped config path (from appdata) to the tank_cmd.py

It would also be useful to be able to run the things like app updates on a local dev environment so we could pull latest updated app versions and then commit them into the git repo.

Just wondering if there’s a nicer way to do it? Or do stop me if I’m way off the mark here…

Cheers!

3 Likes

Hi Jared

Welcome to the forums, this is a good question.

I’m actually in the middle of writing up a guide that covers exactly this scenario. Unfortunately, that part is not ready to share just yet. However, I can share a snippet of code here.

import sgtk
sgtk.LogManager().initialize_custom_handler()
sgtk.LogManager().global_debug = True

sa = sgtk.authentication.ShotgunAuthenticator()

# Use the authenticator to create a user object. This object
# identifies a Shotgun user or script and also wraps around
# a Shotgun API instance which is associated with that user.
user = sa.create_script_user(api_script="scriptname",
                             api_key="script key",
                             host="https://yoursite.shotgunstudio.com")

sgtk.set_authenticated_user(user)

mgr = sgtk.bootstrap.ToolkitManager()
mgr.plugin_id = "basic.shell"
project = {"type": "Project", "id": 89}

engine = mgr.bootstrap_engine("tk-shell", entity=project)

# # we don't need to do this but it may be useful to see what commands are available
# for command_name, command_dict in engine.commands.items():
#     # print out the command name and the command dictionary
#     print "----------\n%s\n%s" % (command_name, pprint.pformat(command_dict))

# run an app registered with the engine
engine.execute_command("Show Starter Template App...",[])

# get useful API objects from the engine, that you could use for scripting.
tk = engine.sgtk
context = engine.context
sg = engine.shotgun

Let me know if you have any questions around it.
Cheers
Phil

2 Likes

It was the end of my day yesterday and I didn’t have time to cover all your points.

With distributed configs, it is not intended that you would run the tank command. One does exist but it is buried inside the cache, and also not suitable for things like updates where it modifies the config since it would only modify the cached version.

Using a bootstrap script is the way to go here. The bootstrap process should pull down everything it needs including the config and all it’s dependancies. All you need to ensure is that you have a copy of the sgtk core some where which can be imported and used to initialise the bootstrap.

You could turn your bootstrap script into accepting command line args if you would like, and then just pass the name of the command that you would wish to run?

1 Like

Hi Phil,
Thanks for your reply.
The script you sent over is pretty much exactly what I had already (good to validate I was on the right track).

In terms of the tank command, good to know that it’s not intended to be used. I can see why you wouldn’t need things like cache apps.

Does this mean that the code in sgtk for updating apps is no longer useable? It would be really useful to be able to check for updates and apply them to a local dev branch.

I’ll give it a go passing the name of the command, this should be relatively easy. I just didn’t want to write something if there was already something in place for it.

Thanks for the help!
Jared

3 Likes

It is possible to still run the updates but you can’t apply them directly to a git branch via the Toolkit code.

The approach you can use is,

  1. Pull your git repo down onto your drive.
  2. Set your config to use a dev descriptor to point to the files on disk. You’ll probably want to make a second config entity in Shotgun and restrict it to your self for testing purposes.
  3. Open Shotgun Desktop and navigate to your project, and select the top-right drop-down menu (ensure you have the right config selected) and you should see options for updating your config.
  4. This will apply the update your config on disk, and then you can commit the changes to your git branch, and push to the remote.

Note: there is a “Check for core updates…” option but this is currently not working, unfortunately. The work around it to just modify the version number in the config/core/core_api.yml

Also covered here.

1 Like

Oh, were those added in a core update? We don’t have those options and we’re quite a bit behind the core versions at the moment (issues with a gateway that we can’t seem to get rid of).

1 Like

Ah no problem. It’s actually an app, called tk-multi-devutils.
It’s added by default to the more recent tk-config-default2 configuration releases. You can add it to your config by copying the following lines to your config.

2 Likes

Great, that’s appearing now, thanks! I’ll have a look into that app as I want to build some developer tools for introspecting our rez environment and performing some basic testing.

Cheers, this has been really helpful!

P.s. I think we might need to get into the habbit or merging the tk-default-config2 back into our branch as I’m wondering what else we’re missing :wink:

3 Likes