Is it possible to specify a package version when using referenced packages with ‘Run a Script’ steps? It appears that the latest package versions are included but aren’t subject to the versioning associated with creating a release:
Step screenshot:
Thanks for getting in touch with us, and that’s a good question.
I believe if you instead create a parameter for the package (just a single-line text box), then leave the package details for the step template at ‘Select specific package’ instead of ‘Let the project select the package’, you should be able to ‘bind’ that parameter in your step’s script.
For example, I created the following parameter in the template ‘Parameters’ section:
Then within the ‘Step’ section of the step template, add a package reference and select a specific package. From there you should be able to click the ‘Bind’ button (chain links) for the Package ID and click #{} to insert your variable. Lastly, give the package reference a name (e.g. PackageInScript):
My new template for deploying SQL from a worker pool seems to be working well so far; however I’m seeing something strange. If I create a step from the new template (manually or programmatically) everything appears to be fine. The step using the old template is disabled and renamed to ‘_old’ and the new one is created using the settings from the original step:
I’ve dug through the deployment process and the step action settings but I’m not seeing any property names that correspond to this association. How does this occur and is there a way to do it with code?
Thanks for getting back to me with those details, and sorry to see you’ve run into this.
I believe you’re likely running into a known issue, whereby step templates created via the API are missing some referenced packages but I’m curious if you think this matches what’s happening on your end?
Unfortunately, I think this might be what you’re running into since I think the missing package looks like it’s of the form <step template name>/<package id>, but it would be good to get confirmation from you.
Hi Patrick. This is EXACTLY what’s happening on my end. I reviewed the Github issue and was able to figure out a work around . Need to do more testing but so far so good. Really appreciate the help!
Glad to hear you were able to find a workaround! I’ll add this thread as another encounter with the bug, which helps give it weight for getting fixed in the future.
If you don’t mind sharing your workaround once you’ve fully tested it, I would be curious to hear what you came up with. It might be something we can add to the issue and pass along to other users who encounter this and find this thread. No worries if you’d rather not, though!
To get around the problem I created a “template” project with one deployment step based on the new SQL deployment template (the package reference in this step is configured with the values I want to use). When the conversion script runs on any project, I load the deployment process for the “template” project, create a new package reference object (‘Octopus.Client.Model.PackageReference’) for the step in the conversion project, and copy over the package object property values in the deployment process.
Not the most elegant solution , but it works. Thanks!