Octopus CLI - Set package ID param doesn't work

I have the need to use a variable for the package ID of a common release project.

I have set the PackageId variable as a prompt/required variable in the project.

Using the Azure DevOps create release plugin, I specify the parameters and the log shows the following being used:

create-release “–space=Spaces-1” “–project=Projects-363” “–releaseNumber=20210421.16” “–server=https://ACME2.corp.com/ACME” “–apiKey=***” --enableServiceMessages “–deployTo=Environments-262” --variable DeleteFilesInExportFolder:TRUE --variable PackageId:AdventureWorks --variable IncludeIdenticalObjectsInChangeReport:FALSE --version 20210421.16 --variable TargetSqlServerInstance:ACME1.corp.com --variable TargetDatabaseName:AdventureWorks

An error occurs however.

Could not find any packages with ID ‘’ in the feed ‘Octopus Server (built-in)’

Here is the variable listing for the project.

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 in advance!

Hi @iancwright!

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

Thanks for the feedback.

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.

Hi @iancwright,

Thanks for coming back to us so promptly.

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.

Please let me know what you think.

Thanks,

Derek

Thank you sir for that reply!

I will investigate this forthwith and let you know how it goes.

Octo is a great product; my team has been happy to adopt it in our BU.

Regards,

Ian

Hi @iancwright,

Apologies, I had to remove the link to the sample, as it was actually our Internal Octopus that you wouldn’t be able to access.

Let me know how you get on and if I can help in any way.

All the best,

Derek

Hi @Derek_Campbell

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.

Here’s what I did:

When my Azure build kicks off, it pushes the package to the built-in library of Octopus.

The Octopus CLI command used according to Azure is this:

D:\a\1\s>dotnet “C:\hostedtoolcache\windows\octo\7.4.3184\x64/octo.dll” create-release “–space=Spaces-1” “–project=Projects-363” “–releaseNumber=20210422.1” "–channel=Channels-344" “–server=https://ACME.corp4.com/XYZ” “–apiKey=***” --enableServiceMessages --variable DeleteFilesInExportFolder:TRUE –variable PackageId:AdventureWorks --variable IncludeIdenticalObjectsInChangeReport:FALSE --version 20210422.1 --variable TargetSqlServerInstance:ACME.corp3.com --variable TargetDatabaseName:AdventureWorks –releaseNumber 20210422.1 --packageVersion 20210422.1

Octopus says we’re all good to go:

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)

  • Name Version Source Version rules *

  • — ---------------- ------------ ---------------- -----------------------*
  • 1 Deploy Package 20210422.1 User specified Range: PASS Tag: PASS*

Creating release…
Release 20210422.1 created successfully!
setParameter name=‘octo.releaseNumber’ value=‘20210422.1’

What I get in my release:

So the Azure logging tells me it is finding everything correctly (including my new channel) but still nada in the deployment.

Thanks in advance!

Ian

Hi Ian,

Thanks for coming back with so much detail.

I’m going to set this up as a PoC and come back to you. It’ll be next week as I want to be sure before coming back to you.

All the best,

Derek

Hi @iancwright,

Thanks for your patience on this.

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.

Azure DevOps - Default Channel

This gave me a package on the Default Channel that I could deploy.

Azure DevOps - Pre-Release Channel

I cloned the Azure DevOps pipeline, and changed it slightly. I changed the package name to OctopusSamples.OctoPetShop.Database-Pre-Release

In the below, the main difference is that I specified the Pre-Release Channel

This gave me the below in Octopus, which means I could then deploy the newly uploaded artifact.

In Octopus variables, I mapped the PackageID to the different channels:

Please let me know what you think and if you have any questions,

Thanks,

Derek

Hi Derek,

Thanks for the sample.

This has ended up being a much smaller isuse.

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. :frowning: 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.

Hey Ian,

Don’t worry about it, it happens to the best of us.

All the best and Happy Deployments,

Derek