I’ve read the Azure Cloud Service Step doc a few times, but a few things aren’t connecting coming from a continuous integration perspective.
I’m using TeamCity to run MSBuild project files which include the OctoPack targets, configured to run OctoPack to generate nupkg files. These are then published to my nuget feed. When I run octo.exe to deploy a project with a “Deploy Azure Cloud Service” step, it fails with “Your package does not appear to contain any Azure Cloud Service package (.cspkg) files.”
The referenced doc presumes I start with a cspkg file, but I don’t have one after MSBuild completes. I’d guess that there’s some MSBuild target which generates this (via cspack) when the “Package…” action is selected in Visual Studio. Wouldn’t the OctoPack target invoke this target for cloud projects? If not, is there a way to just include the inputs (csdef, cscfg) in the nupkg and build the cspkg during deployment? The unpacking of a cspkg only to modify and repack it would be a simpler process in this case.
An article examining how to use TeamCity and Octopus to publish a cloud service uses a custom step with a script to generate the cspkg file, where the nuget package has only the input files from the project, but it seems that this approach replaces the built-in “Deploy Azure Cloud Service.” Can the built-in “Deploy Azure Cloud Service” start with the input files in the same way?
Thanks for reaching out. Octopack’s job is to pack the output of your build into a Nuget package that is compatible with Octopus Deploy. It is up to your build configuration to tell MSBuild to pack your service into a cspkg file at the end of the process, so octopack can grab the cspkg and put it into the NuGet package.
Yes, OctoPack takes the msbuild output and makes a package, but it also has some intelligence about what that output is. For example with ASP MVC sites, it knows to grab the content files as well as the files in the bin dir. So there is some knowledge about the targets. Is there no knowledge about Azure services in the same way?
But ultimately, creating a cspkg on the build server only to unpack it on the Octopus Server and repack it seems overly complicated. Why not just let OctoPack package the csdef and cscfg output files into the nuget package, and build the cspkg as part of the deployment? Is this not possible with the current tools?
Sorry for the delay here. When we designed our Cloud Service deployment approach, we handled a couple of options, and among them we thought about just getting the cloud service files from the nuget package and then packing them into a cspkg file from Octopus. See Option 3 on this github issue as a proof of that https://github.com/OctopusDeploy/Issues/issues/1604
At the current version, the only approach that will work is having the cspkg inside of the Nuget package as shown in our documentation.
I will forward your question to the developer that worked on our Cloud Service deployment approach, and ask him if there’s a chance that we’ll implement what you are asking for to avoid the “extra repack”. He’s on leave until next week, so please try to be patient while he gets back to you.
I’m getting back to you to let you know that I brought the discussion to the team, and we decided that for now we’ll stick with our current approach and wont be adding the Option 3 mentioned in my previous reply.
Hi,
It’s now April 2016 and I’m hoping that in Octopus 3.3.4 there’s some native support for for what Rory was trying to do here.
I’m using Atlassian Bamboo, but it’s the same principle as TeamCity: I want my Continuous Integration builds to be able to create a NuGet package (with OctoPack) that automatically contains the .cspkg file and can therefore easily be deployed with Octopus.
Is it possible? Or are we still stuck manually building .cspkg files?
With Cloud services, we still require a NuGet package with the cspkg inside it for deployment, and we don’t have any plans at this time to change this.
You can add a feature request to our UserVoice site and see if it’s something the wider community thinks would be advantageous to them as well.
I’m sorry if this is not the answer you were after.
It seems odd to me too that there’s this extra step on the build server side which is then just undone anyway on the deployment in order to repackage it. However, as it is, I’ve created a task which invokes CsPack.exe from the Azure SDK directly to build the cspkg how I want it, generating some placeholder files which are then processed during deployment. This shifts more of the deployment responsibility to the build server than I like, but it works in practice.
Hi Rory. I have a similar issue. I need to deploy cloud service with Octopus and build it with Jenkins server. I am quite new here and any help is appreciated.
What was the step that you added for building .cspkg before making .nupkg and sending them to Octopus server?
Can you please share some code. Its is so few code examples on this matter
I’m facing the exact same problem. The deployments were working fine 20 days ago. Between those 20 days there weren’t any deployments to Azure Cloud Service. When we started doing it again, it is popping “Your package does not appear to contain any Azure Cloud Service package” error. Did all NuGet version related debug, but no luck [http://stackoverflow.com/questions/38416962/why-does-azure-cloud-service-in-octopus-fail-with-error-your-package-does-not]. Not sure what is wrong. Please help
I’m so sorry for our lack of communication on this thread.
@Goran, OctoPack itself cannot be used with a Cloud Service project. However, the following may work for what you’re after:
Have your build process build the publish target for the Cloud Service project, e.g. msbuild CloudService\CloudService.ccproj /t:Publish /p:Configuration=Release
Use Octo.exe to package the publish folder, e.g. tools\octo.exe pack --id=CloudService --version=VersionFromJenkins --basePath=CloudService\bin\Release\app.publish
@Sridattha, are you still encountering this error? If so, would you be willing to provide us with your Cloud Service package that is giving this error? I know it’s a big request - it would provide our best chance to replicate and find the issue. If you’re okay with that, could you email support@octopus.com linking to this thread? We’ll then be happy to give you a secure link that you can upload the package to.
