Transfer package problem

Yesterday 24/05/18 We Upgraded from 4.0.11 to 2018.5.2

Now in one our projects we have a step that Transfers a package called filename.1.0.3.tar.gz
It Creates this filename on the target:
filename@S1.0.3@52CD8E2129679A48A11A9E2F7F068A0B.tar.gz
My following step of Extract package, which runs a bash script (tar -xzvf filename.1.0.3.tar.gz) then fails because it can’t find the file.

I have overcome this by copying the file back to what it should be on the target machine and then running the deployment again - it then works.
But we get the Transfer package step again produces another file with a similar corruption in the name:
filename@S1.0.3@98F7E81822CC604386DDAFF736F4479A.tar.gz

This didnt happen before the upgrade, does anyone know what I can do to overcome this - seems wierd that the file name is changed.
Many thanks
Mike

Hi Mike,

Thanks for getting in touch! This is related to a recent change we have made to the cache naming formats. The following GitHub issue has a lot of information about why we changed this and what we did.

We also have a section in the following blog post where we mention this.

Currently you can reference this new value in your transfer a package step by calling the following variable.

#{Octopus.Action.Package.OriginalFineName}

I had a chat with the team and we are going to look into fixing this so you can continue using the regular filename as you where. In the mean time, the above variable will get you going again. :slight_smile:

Please let me know if you have any thoughts or questions here.

Best regards,
Daniel

Hi Daniel,
When I tried your method it failed complaining that tar needed the -f flag - which it had - but complained because the file name wasn’t rendered correctly, however this does work:

tar -xzvf #{Octopus.Action[NameOfStepThatDoesPackageTransfer].Output.Package.FileName}

Mike :frowning:

Hi Mike,

I’m checking in as Daniel is on some well earned leave. You are correct with your formatting, that is what is required to access what we call an output variable from a previous step.

I also wanted to let you know that we have raised this internally and will be fixing the naming in a future release, however it is fairly low priority for us at the moment as we have a workaround.

Please let me know if there is anything else that I can help you with.

Regards,
Alex

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