When querying the releases endpoint of the API we’re finding that the Package Reference Name value is always empty. However this is clearly visible when checking the step in the UI
For context, the package is pulled via an external feed for each deployment rather than it already being in the Package repo. I’m not sure if this is related to why it doesn’t show in the field?
The relevant snippet of JSON we get back is shown below.
Thanks for reaching out and sorry to hear you’re experiencing issues.
May I ask a few questions, please, just to get an idea of which path to go down for troubleshooting?
Which version of Octopus are you running?
Is the step using that package a step template or an individually configured process step?
Does this happen with all packages or just this package in this project?
Depending on the answers to the above we have a couple of different things we can check, hopefully we can get this resolved ASAP for you!
We’re running version 2022.1.2412 (sorry should have included this at the start!)
Its a “Deploy Windows Service” step template and we’re also seeing it with “Deploy to IIS” steps as well.
It looks like it happens in all projects where we pull packages via a feed. Historically we used to push packages to Octopus when I’ve looked back at those the PackageReferenceName is included in the response.
If the “Name” field inside the step template config is blank, despite having a package parameter set inside the step template, it would result in the behaviour that you’re experiencing.
Have you used this step template previously with the built-in feed when you were making use of this, and it’s only upon swapping to an external feed that this is happening, or did this step template get put into use only when swapping to external feeds?
I’ve done some testing on this myself and my conclusion is as follows:
Steps that allow packages to be referenced in them (aside from the main purpose of the step) such as “Run a Script” and “Run an AWS cli script”, contain a PackageReferenceName, to make reference to a package attached to them from within the script body.
Steps that provide no ability for the user to interact with the package but use a package as their main purpose (Deploy a Package, Deploy a Windows Service), do not contain a PackageReferenceName, as there is no requirement for the user to reference the package within that step.
If the reason you’re looking to identify a package reference name is to reference the package in a future step, then unless you are using a custom install directory, the package deployed via the Deploy a Windows Service step is cleaned up immediately after deployment.
Is there a particular reason that you need to find the PackageReferenceName?
There may be an alternative method to achieving similar results that we can assist you with.
Hi @adam.hollow,
That does sound a reasonable conclusion although its a little disappointing as there’s not clear reason why it can’t be made available. After all it is available when viewing the release via the UI.
I appreciate this is going off topic for the original case.
Our end goal is is to have visibility when package versions are promoted to production so that we can mark the build artefact as “in prod” (and potentially tag the original commit in the repo) hence wanting to be able to get the package name and version from the release.
We use Octo on prem for deployments and Az Devops for our build pipelines which then offers the feed that Octo pulls from. At this time Octo is not in our DMZ and only available internally (so we’re not able to push Build Information to it). Our plan had been to:
Create an Octo subscription for Deployments to Prod
Have an internal endpoint listening for those POST notifications from the subscription
It would be able to read the package name and version number (after querying Octo API for the release info
It would then mark that package and version + tag the repo in Az Devops
Would very much be open to suggestions (I’ll just add that putting Octo on the DMZ is not off the cards for us)
Thanks
Alex
Just jumping in for Adam who is off today. Thank you for explaining your use case in such detail, that does help us see why you would want to reference that package name. From the discussions in this ticket I cant see any obvious way to achieve what you are after but I am going to ask our Solutions team who may have a better way for you to accomplish this.
I will get back to you with any recommendations they have, reach out in the meantime if you have any further questions.
Our solutions team have had a look at this for you and have asked why do you need PackageReferenceName over PackageID ?
They mentioned it sounds like you are trying to query the release to get the packageId, is this correct?
Although it’s not in the release api response, the results from that response can get you the package id, you just have to make two calls:
/api/[Space-ID]/releases/projects/[Project-ID]/releases/[release-number] which gets you two things. The SelectedPackages object which in turn gives you the step name/action name. In addition it gives you the ProjectDeploymentProcessSnapshotId. From that you can call the deploymentprocesses endpoint (see 2)
/api/[Space-ID]/deploymentprocesses/[deploymentprocess-snapshot-id] . From that response, under the Steps collection, you can get the action with the name that matches, and get the Octopus.Action.Package.PackageId property which gives you the package id
Does that help at all or where you looking for a specific step that would do this for you?
The Solutions team have sent me some pictures I thought might be useful for you to see how they managed to acomplish this:
