"DACPAC Package" parameter is disabled and populated with "This parameter is not used by the step"

[danielleshoemake]

Step template

SQL - Deploy DACPAC using SqlPackage

Step version

6

Octopus version

2024.4

Step template parameter inputs

DACPACPackageName: Database.dacpac
Publish profile name: Database.publish.xml
Report: True
Script: True
Deploy: True
Target Servername: #{DBServername}
Target Database: #{DBName}
Authentication type: SQL Authentication
Username: #{DBUsername}
Password: #{DBPassword}
DACPAC Package: "This parameter is not used by the step" <---- this is the issue
Command Timeout:
SqlPackage executable location:
Additional arguments:

What happened

Summary: Using Octopus Deploy 2024.4, SQL Server 2022, and version 6 of the "SQL - Deploy DACPAC using SqlPackage" template; the template seems to require a customization to the "Referenced Packages" configuration. Without configuring Referenced Packages, the DACPAC Packages parameter is prepopulated with This parameter is not used by the step and does not allow us to modify it. If we save a copy of the template, we can add a package to the Referenced Packages section under Details -> Step -> Script. With the addition of this customization, the DACPAC Packages parameter becomes populated with our package and we're able to modify it as it is no longer disabled.

Full Story: (includes getting a different result with an older version of Octopus)

• We upgraded a SQL Server 2016 instance to 2022
• The upgrade led to us migrating from the older "SQL - Deploy DACPAC" step template to "SQL - Deploy DACPAC using SqlPackage"
• We are pretty sure that the newer template was not compatible with the version of Octopus that we were on (2019), so we upgraded to Octopus Deploy 2024.4

We didn't have any issues with the new template parameters on Octopus Deploy 2019, but the ExtractedPath action in this line was returning null: $ExtractPathKey = ("Octopus.Action.Package[{0}].ExtractedPath" -f $PackageReferenceName). At first we thought it was an issue with how we were setting the parameter, but after some testing, it seemed that this action was simply not working. We found some documentation stating that this action is part of a set of new actions so this led to upgrading Octopus from 2019 to 2024.4.

It was at this point that we noticed the DACPAC Packages parameter would not allow us to enter a package name. After poking around the template, we eventually found the "Referenced Packages" section and noticed that this section does not exist in our older version of Octopus. Configuring this section with our package info gets us to "it works" but requires us to fork the template. We can survive with this workaround but would of course prefer the benefits of getting future template updates.

I could put in a PR, but I'm not positive if this a bug, if we've missed something, or if it is perhaps an issue specific to the latest version of Octopus. If someone can confirm that we are not doing something silly and that this is in fact an issue, I can work on a PR; but as it goes, we're in a time crunch with a small team so it might be a few weeks before I can get to it.

Reproduction steps

Using Octopus Deploy 2024.4, configure a new step using the "SQL - Deploy DACPAC using SqlPackage" template.

Expected behavior: All parameters are configurable
Actual behavior: DACPAC Package is prepopulated with "This parameter is not used by the step" and cannot be modified without first forking the template and adding a package to Referenced Packages.

More Information

No response

[twerthi]

@danielleshoemake Are you on the Octopus Community Slack? I'm a little confused as to what you're seeing and a quick call might help clear things up. The DACPAC Package element of the step template is where you choose the package to deploy

In the Help Text under Package ID, it states that the selected package will be referenced by the name DACPACKPackage within the script. The $PackageReferenceName is set to DACPACPackage in line 450

$PackageReferenceName = "DACPACPackage"

When the line you reference, $ExtractPathKey = ("Octopus.Action.Package[{0}].ExtractedPath" -f $PackageReferenceName), uses.

If at all possible, let's connect to make sure I'm understanding what you're experiencing correctly.

[danielleshoemake]

I did see that hardcoded value in the script and at first wondered if it was supposed to have been a variable. What you're showing in your screenshot is not what we see when we add the step template unless we fork it as described above. I would very much appreciate a call. I'm not in that slack channel, but working on that now.

[twerthi]

Understood, hit me up once you've gotten in. I'm under the name Shawn Sesna.

[danielleshoemake]

Just updating with some notes. I spoke with @twerthi and we identified that for some reason, when we add this template, the package reference is dropped and this issue seems to only be occurring for us. We're going to put a ticket in to Octopus support to see if they can help us to figure out why this happening. We're in the middle of testing various upgrades versus starting on a fresh server, so maybe it has something to do with that. If the issue is still open when we get an answer, I'll update with what we learn. Worst case, our forked copy of the template lets us reset the lost reference.