Using zip files as the package for an external feed?

[wayne.courtney]

Hi, I’ve asked previously, but I guess I wasn’t specific enough. I’m trying to set up automated deployments using a windows share that houses zip packages as we use this for all of our applications for migrations; which is currently a manual process.

Are there any further resources to help me set this up to work with our current method? My current assumption is that there would need to be scripting involved since I can find no in-built methods in either the external feeds, or project steps.

[jeremy.miller]

Hi @wayne.courtney ,

Thanks for reaching out.

If you would like to use a share drive as an external feed, your best paths forward here are Using NuGet.Server to Host NuGet Feeds | Microsoft Docs and ProGet | Package your Applications and Components – Inedo.

These two options will create a feed using your share drive that you can then hook Octopus into.

If you don’t go with one of those methods and want to use scripting, there are a lot of intricacies with how Octopus Steps work with feeds and packages that will likely not work out of the box and you are looking at quite a bit of work to get everything working just how you like it, if at all. We can’t really guide you in this area as it’s not something we recommend doing.

Do you think you could use either of those tools I linked above?

Please let me know.

Thanks,
Jeremy

[wayne.courtney]

Thank for the response. As to the more integrated options, unlikely. I’d either need to repackage the already made zip files from our existing migration solution or directly manipulate them.

I assumed it wasn’t recommended, but I’m certain I recall seeing Octopus supported them (zip files as the packages) as that’s rather what prompted our interest.

[jeremy.miller]

Hi @wayne.courtney ,

You’re very welcome.

You shouldn’t need to touch the zip files you’ve already created if you use the above tools. Zip files within a Nuget feed will work. I could be missing something, though. Was there something in our documentation that stated that?

Please let me know.

Thanks,
Jeremy

[wayne.courtney]

Packaging applications - Octopus Deploy

“Zip .zip Standard zip file as created through most common zip programs. Compatible with the built-In repository only.”

Perhaps I’m missing something as I’ve only gotten back to this recently and gone through the tutorials recently, but it seems indicated that its set up for solutions such as ours.

The option is available via the library - packages and manually browse to a single package, but I don’t see how this would be integrated into say daily parse and deployments outside of single use.

Thanks again,
Wayne

[jeremy.miller]

Hey @wayne.courtney,

Thanks for the info.

I’m going to reach out to some colleagues and see if there is a workaround to get nuget/proget to consume zips.

In the meantime, can you take a look at this blog post and see if Maven is something you could utilize?

Deploy and consume ZIP files from Maven - Octopus Deploy

Please let me know what you think. I will update you as soon as I hear back.

Thanks,
Jeremy

[dane.falvo]

Hi Wayne,

I just wanted to kick this along as we had a bit of a discussion around your query. I understand that you are trying to consume packages directly from your Fileshare and that your current process is relativily manual.

I wanted to quickly address these two quotes from your threads:

I assumed it wasn’t recommended, but I’m certain I recall seeing Octopus supported them (zip files as the packages) as that’s rather what prompted our interest.

We have many people who use and consume Zip packages/files within the Octopus Built-in feed or through other package repositories. I wouldn’t say that Zip files are not recommended at all.

“Zip .zip Standard zip file as created through most common zip programs. Compatible with the built-In repository only.”

What this is referencing is that any zip files can be uploaded to the Octopus Built-in repository and utilised (i.e. pushed to deployment targets) without a need for scripting or using another integration tool (like NuGet or ProGet). It would be hosted in the packages directory of the Octopus Server.

Based on these two points in your thread, I believe there might be a bit of confusion around the process of using Zip files as packages within Octopus. I apologize if you realise this already, but I just wanted to highlight how to go from an application installation folder to deploying a zip package via the built-in package repository. This is a very simple example and only one way to achieve this sort of deployment but the aim is to clear up any misunderstandings about how a zip file/package may be consumed from our package feed. I hope it gets you started on exploring the automated side of package deployment.

1. With the application that you wish to deploy, you would want to create a zip file. The name of this file will need to adhere to Semantic Versioning 2.0 (Versioning schemes | Documentation and Support). A file like “Compression Program” could be renamed to “compression.program.0.0.1”

Apart from the installation files you need in your zip file, you would also want to create some instructions on how the package is installed or what to do with the files once they land on the target machine. Octopus automatically looks for and executes a small list of files that could exist in the package. Scripts in packages | Documentation and Support

We’re going to use a file called “Deploy” and it’s going to run some Powershell. This file will sit in the root of the package.

Deploy.ps1 contents:

2. The next step is to upload the package into the feed. You can upload packages via Command line or, for this example were just going to upload it via the Upload Package button on the Packages page:
   
   

3. Finally, Create a project using the “Deploy a Package” step.
   
   

Choose your Target Roles and then select the Package from the “Octopus Server (built-in)” feed.

4. Create a release and deploy as usual.

I hope this helps with any confusion around Zip files/packages. There is a lot more to learn, and one of the best places to start is here: Packaging applications | Documentation and Support

Again, I’m sorry if this was obvious. Please let me know if I haven’t answered your questions or if you need other information. Also, please have a look at the Maven link that Jeremy has provided.

Regards,

Dane

[wayne.courtney]

I do have some follow-up questions; if you’ll indulge me.

I can’t imagine our means is all that unique. We have development that occurs across multiple, sometimes separated version/source control mechanisms; these are then packaged for deployment via zip files that are entered in a main migration web application. Automated consumption of these on a project by project level as they’re posted is what is desired.

Is maven the better method to attain this? This still seems like it would need considerable scripting to function in this manner from how the example is presented for the package upload (Deploy and consume ZIP files from Maven - Octopus Deploy).

[Justin_Walsh]

Hi @wayne.courtney!

Just jumping in for Jeremy on this ticket, since he’s away this week. This is definitely an interesting one! As the guys mentioned, Octopus is designed to ingest data in a structured manner, but there are some ways you could attempt this without going the external feed route.

The first option that could be a periodic task (an Octopus runbook could work here) to scan your share, upload it to the Octopus built-in feed (via API - example script here: OctopusDeploy-Api/PushPackage.ps1 at master · OctopusDeploy/OctopusDeploy-Api · GitHub), then remove the package from the share. From here you can configure Automatic Release creation to create releases and deploy them?

The second thought that came to mind here is that you could make this work by pointing the Octopus built-in feed at your network share (you may need to change your file paths to match what’s expected by Octopus). For details on this, please see Moving Octopus Server folders - Octopus Deploy

In order for Octopus to pick up these tasks, you would either need to periodically or reactively run the Built-in package re-index, that will scan the filesystem for new files, and then add them to the built-in feed. If you wanted to keep this inside Octopus, you could schedule a runbook to run every few minutes to either run the re-index, or scan for changes, and then run the re-index, if you don’t want it to run without changes.

I should note though, this second solution won’t scale well with a large number of packages, as the re-index time will increase with more packages to scan, which could throw off the schedule for picking up changes.

I hope this helps provide a few more options for you.