Any suggestions for Uri Template parsing in Powershell (for creating API-driven Step Templates)

I am looking to write several Step Templates that use Octopus’ own REST API in order to do some orchestration not included in the UI. As part of this I would like to use the HATEOAS links provided by the REST API in the Step Template powershell scripts. This means I will need to use a .NET implementation of URI Template parsing such as:

With such a library in place I could, for example, deploy an entire group of projects to an environment using the latest version of each project without needing to know any REST API paths other than /api – via a reusable Step Template.

Here are a few questions:

  1. Does anyone know of a Uri Template implementation either native to powershell or with more use than the ones I linked above?

  2. What is the best way to deploy a DLL containing a Uri Template implementation to a server running Octopus Deploy so that these Step Templates could be run? I want to avoid manual installation steps if possible. I also don’t want this to be an insecure process.

  3. Any other suggestions for taking advantage of the HATEOAS support built into Octopus’ REST API? Would using a .NET Uri Templates binary be the best options (without reimplementing the Uri Template parsing logic natively in powershell)?

I’d appreciate ideas from anyone out there familiar with these concepts.

EDIT: Alternatively, should I just be using octo.exe instead of calling the API directly?

Hi Jason,

Thanks for reaching out. I’m gonna help you with half of your questions, and try to get back to you about the rest on shortly (gonna ask our devs here about these).

  1. Will get back to you on this one.

  2. Pack the DLL on a nuget package, make the Octopus Server also a Tentacle as well and deploy the package to it

  3. Will get back to you.

Could you give us more info on what kind of tasks do you plan on doing using the API ? If all you’re gonna do is create releases and start deployments, then i’d definitely recommend you to go with Octo.exe



Thanks Dalmiro,

Re: #2: I currently do this for some other meta-deployment operations such as installing and updating .NET deployment helpers that perform extra steps like working with cloud provider services. This is fine for custom solutions, but to refine my question, what if I were to write Step Templates that rely on a binary or powershell cmdlet being installed? Will these never make it into the Library or is there a suggested way to handle this?

As for the kinds of tasks … originally I was looking at this in order to do some of what octo.exe does (create deployments and clone projects, specifically), but there are two main reasons why I’m interested in the API via powershell over octo.exe.

  1. I’d like to avoid having to download an external binary to use Octopus’ API. This is a very minor point, but the API is ~right there~ and Octopus is already running powershell scripts and hosting its own API.

  2. I’d like to just have Octopus talk to itself directly. Instead of having to rely on a binary existing and being installed, I would like to write a series of Step Templates that perform meta-operations on Octopus by having it invoke its own API.

Some examples of Step Templates I might like to create, off the top of my head:

  • Clone an existing project and set any option/setting for it on creation
  • An orchestration Step Template that calls multiple other projects for deployment that only require project names as configuration (easy drop-in for other users)
  • An orchestration step that manually backups up or prunes all releases and nuget packages matching criteria other than the simple aging methods built in to OD now
  • An orchestration step that determines what version of what app was deployed in environment X on a given date, and redeploys those versions for all applications to that environment (an environment-level rollback)

As you can see, there are a bunch of ideas here that go behond octo.exe and would otherwise require custom .NET binaries to perform. I love the ease of reuse of step templates, and so I would much rather see these kinds of operations written in that format. To this end I’m -also- interested in making a powershell cmdlet that uses Uri Templates and the OD API to make querying the API via powershell easier, making OD-focused Step Templates easier to write.

Before I put much time into this project though I’d like to hear if I’m barking up the wrong tree or if this is something that others may be interested in.

Dalmiro, is there any new information on this? Thanks!

Hi Jason,

Sorry for the delay here. We don’t have a specific recommendation for URI template parsing on Powershell unfortunately. Your project makes perfect logic, and its one of the reasons why we made our REST API like this, so anyone can create tools to suite their needs.

So you’re not barking at the wrong tree!



Thanks Dalmiro, I appreciate you taking the time for this sanity check!