We have a project which succesfully deploys to multiple tenants. For a new client, we have to use offline package drop.
The deployment consists of 12 steps; but there is 1 specific step (a simple deploy of a package to a map, which we also do in other steps) which seems to prevent the creation of the artifact.
If i disable it, it runs succesfully and creates a Zip in the Task Summary.
The Task log doesn’t seem to show anything out of the ordinary, only that it doesn’t create the expected artifact. The deployment succeeds, according to the summary.
The “create artifacts from offline drops” is as follows:
| == Success: Creating Artifacts from Offline Drops ==
16:55:04 Verbose | Creating artifact
16:55:53 Verbose | Create Offline Drops as Artifacts completed
Thank you for contacting Octopus Support. I’m sorry you are having an issue with offline package drops.
Would it be possible for you to share a raw task log from this deployment? Also, if you could share your Process JSON, that would be very helpful so that I may reproduce this issue on my end.
Thank you for the fast reply, I attached both a task log which creates an artifact (by disabling step 5: deploy to temp map) and the failing task log, as well as the process json
I have, thus far, been unsuccessful in reproducing this issue on my end. Would you be willing to give me permission to log into your cloud instance to take a look?
Am I right in saying that the OPD target used for both of these steps is the same OPD deployment target?
I wonder if it’s worth testing creating a new OPD target with the same details but a different name and pointing Step 1 or Step 5 at the new target, to see if there’s still an interaction there?
Let me know if you’ve already tried this, as we’ve been unable to reproduce it so far it’s difficult to do much testing!
No problem.
The OPD target is indeed the same one for all testcases, I will try creating a new one in a short while and get back to you with any findings I have!
We tried using another deploy target and it makes no difference. We did however come to the conclusion that the troubling step succeeds with another, identical nuget package (with another name). Is there any way i can securely transfer these files to you? Seeing that it concerns confidential data.
The upload had finished, the “shell” package is the succeeding one, and the “squirrel” one the failing.
As you can see, they are pretty similar.
The project we tested it with was “BouwOffice vNext - Local Package drop - trial” in the Release project group, to target “PackageDrop” (which is a dummy).
I’ll have a look over them, and if I can’t find anything too suspicious, I’ll send over the files to our engineers to have a closer look; they’d likely be able to spot what’s going on!
Any issues in the meantime, please reach out, and we’ll do our best to assist.
Thanks for reaching out again, and please accept my apologies for the lack of movement on this post.
Unfortunately, I couldn’t find anything suspicious in the files you sent over. Would you perhaps be able to send over some fresh ones to a new link so that I may forward these to our engineers, please?
The files expire after a week or so of being hosted on our platform; I’ve created a new link here: Support Files.
Have you experienced any different behaviour since our last communication, or is everything still functioning as it was before?
I’ve taken another look at everything and discovered that your cloud instance is running out of memory during this operation, which is causing the issue.
I went ahead and scheduled your instance to reprovision during your next outage window and will double the available memory at that time.
I’m also going to reach out to our Development Team to see about getting an error thrown up in the deployment itself when this occurs.
If you have any additional questions, please let me know. Otherwise, once you get a chance to attempt another deployment for this project tomorrow or next week, let me know if it works as expected.
