If I enter a default value of AdventureWorks for package ID in the UI screen, the release creation works.
The package version for some steps was not specified. Going to try and resolve those automatically… Finding latest package for step: Deploy Package Selected ‘AdventureWorks’ version ‘20210421.19.0’ for ‘Deploy Package’ Selected the release plan for Channel ‘Default’ - it is a perfect match Using version number provided on command-line: 20210421.19
I would like to use a parameter for the package ID since I have a generic release process for several databases. I do not want to create separate projects for each of them.
Thanks for reaching out and for the great question! Sadly, this mechanism won’t work in this scenario, as prompted variables are a deployment option, and not a release option. You can specify them with the create-release command because you can set off a deployment as well here.
From the sounds of things, you’re looking for something more along the lines of Dynamically selecting packages at deployment time - Octopus Deploy, but this isn’t an exact match. This exact scenario isn’t one that we expressly support. You could perhaps use the Tenants feature to accomplish this, but again, it’s not an exact match.
I hope this helps, and if you would like some in-depth help with your specific scenario, please don’t hesitate to reach out to our Solutions team at advice@octopus.com
If I am understanding correctly, I cannot create a re-usable step so that different packages can go through the same exact process.
Instead I need to manually run the process, entering the variable values each time.
This is really contrary to the spirit of CI/CD and devops.
Use case:
I have dozens of databases, many of which run under RedGate SQL Change Automation. The plugin mentioned in your documentation works fine for manual deployments. I’ve worked thru the sample from Octopus.
For a release of SCA, I want the Azure DevOps pipeline templates to be re-used. Parameters are supplied etc and this works great. I can trigger the SCA release build which only does a “release” by creating data drift reports, SQL scripts, etc.
Right now, I have one team mate who manually does this every day for every database deployment request. The reports we get from this process are invaluable in helping us determine whether something is potentially going to break a database.
Setting aside RedGate completely, I want to make the point that this gap in Octopus where users are not able to automate a generic process by a package is really, really odd. I’ve seen it mentioned in issues raised years ago and I still cannot believe it has not been solved. The recommendation to create separate projects for every build is understandable, but there are certain generic processes like database validation that do not need the tedium and overhead of setting up individual projects.
The Azure pipeline templates work really well with the SCA plugin for Octopus, but just breaks on the inability of the CLI to support parameters set by a project. I have wasted a lot of time trying to get this working because it never occurred to me that Octopus wouldn’t support such a basic use case.
Overall, I’m happy that I recommended the product to my team and we adopted it in our BU; I’m just surprised by this gap.
I’m a Senior Solutions Architect in the Customer Solutions team here at Octopus and Justin asked me to take a look at this.
One thing to consider would be Channels. In your setup, you could map each Package ID to a different channel in Octopus, and this should resolve your issue.
As a follow up, I did create a channel in my generic project. I’m probably missing something here, but I still end up with the same problem of Octo not being able to locate the package.
Found space: Default (Spaces-1) Space name specified, process is now running in the context of space: Default Handshaking with Octopus Server: https://ACME.corp4.com/XYZ Handshake successful. Octopus version: 2020.5.9; API version: 3.0.0
*Authenticated as: ** *
*Found environments: * This Octopus Server supports channels Found project: Create SCA Database Release (Projects-363) Building release plan for channel ‘Channels-344’… Found channel: SCA Production Comparison (Channels-344) Finding deployment process… Finding release template… Using version number provided on command-line: 20210422.1 Release plan for Create SCA Database Release 20210422.1 Channel: ‘SCA Production Comparison’ (this is the default channel)
The good news is that I have it working as expected. I think the bit you’re perhaps missing, is the channel version rules. I want to be upfront, this is is also a very simple way of trying to get what you’re after.
In Azure DevOps, I started with a cloned sample I had used in the past. I create two pipelines, one for the default channel and one for a Pre-Release channel.
The RedGate SCA outputs a nupkg as yyyymmdd.x.y when it runs its own build.
For example: 20210426.1.0
I was using $(Build.BuildNumber). There is no second period followed by a zero.
Thus, when it went to look in the feed, it didn’t find it. I was finding 20210426.1. This is what Octopus looked for as well because that is the parameter it was given.
Apologies for this. I did not do enough checks.
When I hardcoded a built-in package version number FROM COMMAND LINE parameters that I knew were in Octopus, everything worked fine. I got my delta reports and SQL scripts.
So, this to say that the product’s handling of parameters is there and it works really well for the use case I have, it’s just that the step I was using employs a different version format.
I did not do enough checks.