Since upgrading from Octopus 2021.3.12205 to 2022.2.7362, I’m getting warnings with the following unhandled exception on the Octopus server when deploying to an offline deployment target:
Thanks for reaching out! I’m sorry to hear you’re having trouble with this particular deployment process since upgrading Octopus versions, but I’m happy to help take a look at this.
As a first step, could you try running a System Integrity Check and let me know the results? This should return something like the following:
Also, would you be able to provide the raw output for this particular task?
Here is a secure upload link for this information, in case you don’t want to post it publicly on the forum.
Looking forward to hearing back from you!
Thanks for uploading those!
The System Integrity Check looks good so I’m glad we can rule this out as being a potential issue.
In reviewing the server task log you sent over I noticed that the zip file being created at line 840 has an odd naming structure with a few spaces in it, and I’m wondering if this is the source of the issue you are seeing, as this seems possibly related to the error message being thrown by Octopus here:
at Octopus.Core.Packages.FileNameEscaper.Escape(String input) in ./source/Octopus.Core/Packages/FileNameEscaper.cs:line 27
As a next step, could you try using a package name that doesn’t have these extra space characters present to see if the deployment process behaves any differently?
Hopefully this helps shed some light on the underlying issue, but feel free to reach back out if I can be of any more help.
Thanks for the quick response. I didn’t want to modify my deployment process. Instead, I’ve simply re-ran the deployment but excluded the steps where I .zip the offline package and upload it. Still the same result. I’ve uploaded the raw output to the link you give me earlier.
Thanks for following up and providing all of this information so far. I’ll jump in here for Britton since he’s now offline as part of our US-based team.
I’ve attempted to reproduce this issue locally, but with no luck unfortunately. Would you be willing to provide us with a bit more information so we can hopefully accurately reproduce this issue? I’m interested in having a look at a screenshot of your offline drop target configuration (in your web portal under Infrastructure > Deployment Targets > [Your offline drop target]), and also the deployment process JSON (in your project’s process tab as shown below).
I look forward to hearing back and getting to the bottom of this one!
Here are the details of the off-line target – there’s not that much here. Was this what you were looking for?
The json for the deployment has been uploaded to the link provided earlier.
Thanks for sending that over, and apologies for the delay in getting back to you.
We still haven’t had much success in reproducing this issue on our side, so as a next step would you be able to upload a copy of the package you’re working with in this offline deployment process so I can take a deeper dive on this? This should allow us to build a better picture of what’s happening on your side and hopefully help in identifying the underlying issue here.
Thanks for getting back to me. It wouldn’t hurt to also have a copy of your database to review alongside the package that is being dropped off within this process, if you wanted to upload these to the link I provided previously.
Once I have all this I will try and take a deeper dive on your issue, and I’d also like to sync up with our Australian support team later today as I know they’ve been investigating this on their side as well.
Thank you for your patience while we look into this further!
This project is deploying several packages from the internal NuGet repository. Do you need them all? In fact, I have 2 different projects – both suffering from the same problem. Therefore I doubt it related to a specific package as both projects use different packages.
I am uploading the database backup as we speak. If you do need one or more packages (or all) , please let me know.
Thank you for uploading the database backup! I didn’t notice anything off in my initial review, but I was finally able to reproduce this error on my side using a fairly simple setup so it doesn’t look like this issue is specific to your configuration.
Since I have a working reproduction of this issue now I’ve escalated your request to our engineering team for further review and will reach out as soon as I hear back from them on this.
Also, in my testing it looks like the offline package deployment process still completes even though this particular warning is thrown during the package release step - just to confirm, is this your experience as well, or does this warning cause your deployment process to fail completely?
Thank you for all of the logs and process information you’ve provided so far, and I appreciate your continued patience while our team takes a deeper dive on this problem.
Indeed, it’s just a warning and the process completes (does not fail completely). I can still do installs.
Thanks for your support thus far.
Thank you for confirming you can still deploy, that is good to know. Britton will be online in a bit but I have mentioned your comment to the engineers just to make them aware. We will keep you informed of any news.
I just noticed a new version of Octopus deploy, and the release notes of one of the versions in between our current version and the new one explicitly mentioned this issue; I’ve installed it and can confirm that the issue is now resolved.
Many thanks for you support – it’s always good to have a deployment process without warnings
That’s excellent news, I’m happy to hear that the latest version of Octopus Deploy resolved this for you!
It sounds like we should be all set here now, but let me know if I can be of any more help.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.