Is it possible to manually copy a package to a machine and install it? While Octopus would work for 80% of our customers, the rest have machines with absolutely no internet access. We would need the ability to email/ftp a package to our customer and have them install manually. I really don’t want to have two separate deployment methods, because things are bound to get messed up 
Thanks,
Brian
Hi Brian,
Tentacle.exe supports XCopy deployment, and you can use the command:
tentacle.exe deploy-package -f YourPackage.nupkg
To deploy the package and run the conventions. Any variables can be passed in with the -v parameters too. We plan to do more with this feature in the future but for now it’s the best we can offer.
Hope that helps,
Paul
Hi
I have tried the above solution but without luck, I have two different error messages.
The -f argument is not allowed.
The command is not supported.
Any help to this problem is appreciated.
Christian
Hello,
The deploy-package command is no longer supported in Octopus 2.0 unfortunately. It’s something we’ll be bringing back for Octopus 2.5. Sorry for the trouble, it will be back soon!
Paul
Hi Paul
Thank you for your answer.
Maybe you have an idea how to handle my problem.
My problem is:
We have 3 locations. Development, Customer test, Production.
I have basically setup the development location to use Octopus.
My problem is that customer test and production is 2 different locations, each behind VPN and special accessing applications.
Is there any way I can copy the release definition to the other locations after I have created it on the development location.
I know I can setup a server on the two other locations, but then I have to create the release again, which can make the customer a bit curious.
Do you have any smart ideas how to solve this problem?
Regards,
Christan Hansen
Hi Christian,
We’re currently working on some release import/export functionality via Octo.exe that may assist with this. Timeframe is not currently concrete however.
You might alternatively investigate “polling Tentacles”, which pull from the Octopus server and thus work in a wider range of locked-down environments. Is there any chance this might help?
Regards,
Nick
Hi Nicholas
I think I will wait until the import/export feature is included.
So for now I have to find another way to deploy things.
Thank you for your input.
Regards,
Christian
As an aside on this, is there even a way to trick the Tentacle into thinking the package has been uploaded?
We’ve run into issues with transferring the packages, but the tentacle and server can otherwise communicate just fine. I’ve tried manually placing the package in the tentacle folder, but because it appends a GUID at the end of the package name, there’s no way for me to know that ahead of time and rename the package accordingly.
It would be great to just have a way of placing the package in the folder and having the tentacle recognize the package already exists, and continue on the deployment without package transfer.
Copying the package into the Tentacle folder will probably work - the GUID at the end is random so it doesn’t matter what you use. Octopus looks for packages in the folder and reads the NuPkg manifests and compares hashes (the GUID in the filename is just used for uniqueness). It’s not really a supported scenario, but I’d expect it to work.
Paul
Unfortunately I just tried this, and it checks for the file with the hash appended, so i upload the package anyway. This was my attempt at placing the package in C:\Octopus\Applications.Tentacle\Packages…
Perhaps this only happens because I am using an external nuget feed? I’ve query’d the REST API for TeamCity and the hash is not included, so perhaps then Octopus gets the package it appends it?
I’ll try with an internal package and report back.
No luck. Even packages hosted on the Octopus server get the following line in their raw output:
SHA1 hash of package is: …
And then it upload the package with the hash at the end.
If the ability to ignore this and just use the package name, that would be great. Otherwise, there’s no way to deploy.
UPDATE: I had misread your initial suggestion, Paul, and I had not included a GUID at the end of the package name, I merely placed the nupkg in the folder. I tested it again today by appending a new GUID after the package name, and it successfully recognized the package on the target machine and did not upload it.
This gives me a temporary workaround, but it would be nice if in 2.5 or 2.6 we could get the ability to just place the package in the folder and tell Octopus to deploy, that way I don’t have to generate GUIDS after package names.