We have a web application that has a bunch of static content for the help file that we used to deploy manually but which we recently included in our repo so that it would be deployed automatically with the rest of the site through Octopus. The app itself has been and continues to be deployed without any problems, but now after adding these additional files it’s not deploying them and I cannot figure out why. This is just a folder sitting at the root.
I’ve verified that the files are in the package and I’ve even tried adding them explicitly to the nuspec file but nothing seems to work.
The logs only list that files have been extracted, so I can’t get any more information from them.
I feel like I’m missing something small, but I’ve gone over all the configurations already and I’m coming up blank. Any help would be greatly appreciated.
I was just able to get the folder deployed be creating a new release (not a new build). I believe this problem may stem from the fact that I had a newer version package in the package repository. We sometimes need to push a newer version to our testing environment while still having older versions available to go to production. Specifically, I was trying to push a 1.23 version and I had a 1.24 version in the package repo.
Can anyone explain to me what is going on here? If a newer version package being in is the cause of this problem it will be a big issue for us.
Thanks for reaching out. When you were trying to deploy your 1.24 package, were you by any chance trying to re-deploy the same Octopus release that initially deployed the package 1.23?
If you need to deploy a new version of the package, you need to either create a new release (*) or edit the release you are trying to re-deploy to use the new package(** and see attached screenshot)
(*) Super recomended - In Octopus we encourage people to follow the practice of creating a new Octopus release if you are going to deploy a new version of a package. Having the release with the exact same version as the package you are deploying on it is by far the best practice.
(**) As you’ve read above, we are not fans of this approach but we do understand some users might need it.
All our releases are created through TeamCity when builds occur. I’ve got two configurations there, one for our new branch and one for the stable branch. I set the versions there so that the new branch will build versions one minor version higher.
What I’m finding is that if the new branch pushes out a package (e.g. 1.24) and then the stable branch pushes another (e.g. 1.23), the fact that a 1.24 package is available seems to screw up the deployment even though the release is using the 1.23 package.
Actually, I’m looking at the logs now and it seems that the 1.23 release that was being deployed is actually pulling the 1.24 package.
I’m going to go through our create release step in TeamCity and see if that is where the issue is. I’ll get back to you then.
So this problem was sort of two fold. The first part being that when TeamCity was creating the release, it wasn’t specifying the package version so Octopus was always using the “latest” version. I had to update my create release step in TeamCity to include the “packageversion” parameter and that worked.
So what I’ve got in the additional parameters is this: --packageversion=%build.number%
That forces each created release to pick the package with the version that was just pushed.
