Release deployment not updating package with newer version

Legacy Uncategorised
1

I’ve only noticed this recently, so it could have begun with my [also recent] upgrade to v3.4.0 (and v3.4.2 today).

We prefer to use date for version numbering and we don’t deal in pre-release versions, just release vs debug. After several tries, we have reworked the version into an almost SemVer 2.0-compatible format: YYYY.MM.DD0HHMM+rel (or +dbg).

We looked at the deploymentjournal.xml in the Octopus folder after a deployment and realized that two fields don’t get filled in for the package that won’t update (HeliosOne) - PackageId and PackageVersion. They do for another package that updates correctly (CentralServices) and uses the same version numbering.

Ideas are welcomed.

DeploymentJournal.xml snippet for package that will (CentralServices) and package that won’t (HeliosOne) -

Deployment details for HeliosOne (package that will not update) -
HeliosOne Version on Server: 2016.08.2901354+rel
HeliosOne Version in Release: 2016.08.2901419+rel

Deployment Log:
Deploying package ‘D:\Octopus\Files\HeliosOne.2016.08.2901419+rel.zip-b239571a-21a8-4dd8-ad07-31d082b33dc7’ to machine ‘https://omaedchap341:10933/’

August 29th 2016 14:20:36
Info
Deploying package: D:\Octopus\Files\HeliosOne.2016.08.2901419+rel.zip-b239571a-21a8-4dd8-ad07-31d082b33dc7

August 29th 2016 14:20:36
Info
The package has already been installed on this machine, so installation will be skipped.

2

Update: It’s specific to being the first or second step in the deployment. If I switch and make the HeliosOne step first and the CentralServices second, then HeliosOne deploys correctly and CentralServices doesn’t. If I force the deployment, the deployment journal includes no PackageId and PackageVersion fields for CentralServices.

3

Hi Rose,

I’m sorry to hear you’re experiencing this issue.

I am currently investigating; to assist, could you possibly attach the raw task log of a deployment please?

Regards,
Michael

4

Michael,

I’m attaching the raw task log. The package HeliosOne is the one that failed to update.

Thanks,
-Rose

ServerTasks-916.log.txt (38 KB)

5

I created a simple Project and a simple Process with 2 Deploy Package steps.
Versioning of packages was kept simple x.y.z.

Attached are 2 raw task logs.
On first deployment PackageA’s deployment journal entry was correct and PackageB’s was not (blank id and version).
I changed the order, created a new release and force deployed it.
In this second deployment PackageB’s entry is correct and PackageA’s is not.

ServerTasks-948.log.txt (8 KB)

ServerTasks-949.log.txt (11 KB)

6

Thank-you both for supplying the logs.

We were able to replicate this problem. I have created an issue, which we have now committed a fix for. This will be in release 3.4.3, which should be available in the next day or so.

As a temporary work-around (because I imagine this is rather a blocker for you), you should be able to add a project variable Octopus.Action.Package.NuGetPackageId and set it’s value to #{Octopus.Action.Package.PackageId}.
Caveat: I haven’t personally confirmed setting the variable resolves the issue.

We sincerely apologize for any inconvenience.

Regards,
Michael

7

Thank you, Michael.

I tried the workaround. It only caused the PackageId to be correct; the PackageVersion is still blank.

My DeploymentJournal.xml files are now full of entries with blank PackageId and PackageVersion. This might also explain why the releases of the 2nd package are never cleaned up. I was tempted to remove all those entries, but I’ll leave them to see how it behaves when I upgrade to 3.4.3.

Looking forward to the update :slight_smile:

-Michael

8

Michael,

Of course! I apologize, you would need to create a similar variable for PackageVersion.

i.e. Create Octopus.Action.Package.NuGetPackageVersion and set it’s value to#{Octopus.Action.Package.PackageVersion}.

You are correct, you may want to perform some manual clean-up after 3.4.3.

If you have any questions regarding how to proceed once you have installed 3.4.3, don’t hesitate to ask.