Manually pushing packages

We have a setup that requires the use of 1 dynamic package, we are currently using a NuGet server to pull this package from within our network. As we branch out to other clients that are not hosted with us, we’re looking for a solution that requires less overhead (not having to adjust our firewall for every new host). Is it possible to use Octopus.Client or Calamari to manually push a package from our repository to a tentacle? We believe that this may be the most efficient method as external clients will already have to allow us to communicate over port 10933. I’ve looked through the step template library on github and some of the Calamari and Octopus.Client/Server commands, but am having a difficult time figuring out how we would manually trigger the push. Since the packages are dynamic and have to be built at deployment run time, we can’t use the artifact gathering step at the beginning of each deployment to collect the package.

Hi Tony,

Thanks for reaching out, We dont currently have any inbuilt support for the scenario you are describing, however there might be a work around that could work.
The package acquisition step (where the packages are collected up to be transferred) only happens just before the first “Deploy a Package” step, so technically you could create the package and publish it to your external feed in the first step of you deployment, as long as that step occurs before any deploy package steps.
You would also need to select the option to deploy the package from the Octopus Server so that the tentacle doesn’t need to communicate with the NuGet server.

here is some sample code that pushes a package to the Octopus internal package feed, this could be run during the first step in a deployment.

$ver = $OctopusParameters["Octopus.Action[Deploy].Package.NuGetPackageId"]

//run scripts to build a package using the version specified in the deployment
cp D:\ D:\dummy.$

//run a command to upload to the package feed being used.
octo.exe push --package D:\dummy.$ --server http://localhost:8065 --user admin --pass Password01!

Hopefully I have understood your question. I hope that helps, please let me know if you have any further questions,

Kind Regards,
Tom W

Hi Tom,

I'm running into a few issues and was wondering if I could run them by you. I set a variable in my create script that sets the package name in a step called "Get machine roles"--

# Remove white space from the machine name so we can refer to it when we get dynamic files
$machineName = $OctopusParameters['Octopus.Machine.Name']
$packageName = $machineName -replace " ", "_"
$packageName = "Bridge." + $packageName
Write-Host "Package Name: $packageName"

One issue has to do with the output variable I’m using. Here’s what I’ve setup–

I believe this should be something like–
#{Octopus.Action[Get machine roles].Output[Octopus.Machine.Name].packageName}

But trying this doesn’t seem to expand the variable–

Also, it looks like I have to tie a version to this package every time I create a release. Is there a way I can tie this to an input variable rather than specifying this every time I create a release?

Hi Tony,

Regarding the error with the package name not being resolved from the variable, you will need to capture the variable from the first step with the Set-OctopusVariable command as described here, and then you can reference it in the following step
using your example the first step would be

# Remove white space from the machine name so we can refer to it when we get dynamic files
$machineName = $OctopusParameters['Octopus.Machine.Name']
$packageName = $machineName -replace " ", "_"
$packageName = "Bridge." + $packageName
Set-OctopusVariable -name "PackageName" -value $packageName

and then in the binding section of the package step you can reference the variables with
#{Octopus.Action[Get machine roles].Output.PackageName}

Regarding having to enter the version for every release, this is a current limitation of using package name variables and we don’t currently have any way around this.

I hope that help, please let me know if you have any further questions.

Kinds Regards,
Tom W

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