Replace=true does not update Meta data around pachage

This is a bug in Octopus Deploy version v2019.3.1 LTS

We are using GitLab for our CI/CD to test and build packages which is later uploaded to Octopus and then a deploy is started with Octo.exe.

Some projects are using curl to communicate with Octopus to upload the package and using the ** ?replace=true** flag to replace existing library item

Example:
curl --verbose -k -X POST https://octopus.diaverum.net/api/packages/raw?replace=true -H “X-Octopus-ApiKey: $Octopus-API-KEY” -F “file=@dcare-api.$VERSION.tar.gz”

This has been like this for quite some time. But since v2019.3.1 there is a bug in our Octopus installation at least where the packages gets uploaded, but the meta data in Octopus doesn’t.
So when entering the Library in Octopus and looking aht the specific file. All meta data is from the previons version Published and SHA1 hasn’t been updated (all the other fields should remain the same)

But if I choose to download the package by pressing “Download” I get the newest version which was uploaded.

And if you try to deploy. Octopus finds the file in the local cache, so it will check against the SHA1 I presume, which is the old one. So deploy doesn’t deploy latest version.

Attaching GitLab log of the upload if it helps:

gitlab.log (4.1 KB)

Hi @Tobias,

Thanks for getting in touch! I believe this has been resolved in our fast lane release Octopus version 2019.4.0.

The following GitHub Issue has the details for a fix relating to metadata not being pushed when overwriting a preexisting package.

I do not believe we will be patching this into the LTS, so if you are unable to update to the fast lane release you will need to wait for the next major LTS release.

Let me know if you have any further questions here. :slight_smile:

Best regards,
Daniel

Ok, thanks. I missed out on the GitLab issue. Only searched this forum here.
Then I know it’s fixed in that version and we can update to that one…

We can then close this issue here.

BR
Tobias

By the way… If you ever do a 2019.3.2 LTS.
Please include that github issue. I think this is quite a major bug to be honest, and we normally only go for the LTS deploys.

BR
Tobias

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.