Hi, Bob and I spoke about this build step at the time he was writing it. I have just tried move some of our existing build steps to it and found it needs an API key to be defined.
I just wondered why this was required when the other ‘standard’ build steps (that I’ve used) don’t need it. It’s not a problem to create an API key, but I’d rather not do it and find I’d changed 100+ projects that didn’t require it.
The built-in steps are able to make use of the underlying Octopus code, so, when they make use of the API they can do so at a system level.
Any community steps, like the one Bob has created, don’t have the same level of access within Octopus, so, in order to interact with the API in the same way as the built-in step, they require an API key to be generated and assigned to them.
When creating the API key, I would advise to create a new Service Account with the required permissions and generate the API key for that account. This is better than using a key that is linked to a normal user account that may be deactivated at some point in the future.
That is correct. Community step templates such as these don’t have the same low-level access as built-in steps. In order to access the data on the Octopus Deploy instance, it has to go through the Octopus Deploy REST API.
Does this mean community step templates are “inferior” to built-in steps? I’d argue no for the following reasons:
Except in very specific cases, the Octopus Deploy REST API is backward compatible. The step I wrote, should work with any version of Octopus Deploy 2019.x+. This means you don’t have to install the latest version of Octopus Deploy to get access to it.
A community step template is decoupled from the Octopus Deploy install. This means when there is a bug fix in the community step template you only have to install the latest version of the step template. You don’t have to upgrade your entire instance.
The built-in steps run under the context of the current user. This is a double-edged sword.
Going through the Rest API opens up some interesting avenues for security. You could lock down production to only allow deployments through a specific set of service accounts.
Any step templates we write are supported. Report any issues or bugs to advice@octopus.com. In general, the turnaround time is much quicker as we only have to test one step template, not the entire Octopus Deploy server, to push out an update. As you can see in the commit history there have been several modifications based on user feedback. History for step-templates/deploy-child-project.json - OctopusDeploy/Library · GitHub
Anything that can be done via the Octopus UI can be done via Octopus Deploy Rest API. In several cases in this step template, I was able to re-use a ton of existing logic to calculate various business rules.