Tentacle not updating properly

Steve_H · 20 February 2013 17:40

Hi,

I’ve checked the package as deployed to the tentacle and the contents are what I expect, however the files are not updating in the destination folder.

There’s no sign of any errors in the log (this is just the tentacle section):

2013-02-20 17:08:24 INFO Begin deployment
2013-02-20 17:08:24 DEBUG Deploying package www.enterprisestudy.com 4.5.0 to tentacle http://beta2:10933/
2013-02-20 17:08:36 INFO Job successful. Tentacle output follows:
2013-02-20 17:08:24 DEBUG Begin deployment of package: www.enterprisestudy.com.4.5.0
2013-02-20 17:08:24 DEBUG Tentacle Agent information is below:
2013-02-20 17:08:24 DEBUG - Machine name: BETA2
2013-02-20 17:08:24 DEBUG - Is 64-bit: True
2013-02-20 17:08:24 DEBUG - Service user name: SYSTEM
2013-02-20 17:08:24 DEBUG - CLR version: 4.0.30319.18033
2013-02-20 17:08:24 DEBUG - Current directory: C:\Windows\system32
2013-02-20 17:08:24 DEBUG - OS version: Microsoft Windows NT 6.2.9200.0
2013-02-20 17:08:24 DEBUG - Tentacle version: 1.3.0.1535
2013-02-20 17:08:32 DEBUG Conventions will be run in the following order:
2013-02-20 17:08:32 DEBUG - PowerShellPreDeployScript
2013-02-20 17:08:32 DEBUG - DeletePackageFile
2013-02-20 17:08:32 DEBUG - XmlConfigTransforms
2013-02-20 17:08:32 DEBUG - XmlConfigVariables
2013-02-20 17:08:32 DEBUG - CopyPackage
2013-02-20 17:08:32 DEBUG - PowerShellDeployScript
2013-02-20 17:08:32 DEBUG - IisWebSite
2013-02-20 17:08:32 DEBUG - PowerShellPostDeployScript
2013-02-20 17:08:32 DEBUG Looking for PowerShell scripts named PreDeploy.ps1
2013-02-20 17:08:32 DEBUG No scripts with a .ps1 extension were found.
2013-02-20 17:08:32 DEBUG No scripts ending with PreDeploy.ps1 were found.
2013-02-20 17:08:32 DEBUG Looking for PowerShell scripts named PreDeploy.ps1
2013-02-20 17:08:32 DEBUG No scripts with a .ps1 extension were found.
2013-02-20 17:08:32 DEBUG No scripts ending with PreDeploy.ps1 were found.
2013-02-20 17:08:32 INFO Deleting package: d:\Octopus\Applications\UAT\www.enterprisestudy.com\4.5.0_10\www.enterprisestudy.com.4.5.0.nupkg
2013-02-20 17:08:32 INFO Looking for any configuration transformation files
2013-02-20 17:08:32 INFO Looking for appSettings and connectionStrings in any .config files
2013-02-20 17:08:32 DEBUG Scanning configuration file: d:\Octopus\Applications\UAT\www.enterprisestudy.com\4.5.0_10\ServerMySettings.config
2013-02-20 17:08:32 DEBUG Scanning configuration file: d:\Octopus\Applications\UAT\www.enterprisestudy.com\4.5.0_10\ServerSettings.config
2013-02-20 17:08:32 DEBUG Scanning configuration file: d:\Octopus\Applications\UAT\www.enterprisestudy.com\4.5.0_10\serviceModelClient.Config
2013-02-20 17:08:32 DEBUG Scanning configuration file: d:\Octopus\Applications\UAT\www.enterprisestudy.com\4.5.0_10\web.config
2013-02-20 17:08:32 INFO Extracting package contents to 'D:\inetpub\Sites\Octopus’
2013-02-20 17:08:36 DEBUG Looking for PowerShell scripts named Deploy.ps1
2013-02-20 17:08:36 DEBUG No scripts with a .ps1 extension were found.
2013-02-20 17:08:36 DEBUG No scripts ending with Deploy.ps1 were found.
2013-02-20 17:08:36 DEBUG Looking for PowerShell scripts named Deploy.ps1
2013-02-20 17:08:36 DEBUG No scripts with a .ps1 extension were found.
2013-02-20 17:08:36 DEBUG No scripts ending with Deploy.ps1 were found.
2013-02-20 17:08:36 DEBUG The OctopusNotAWebSite variable has been set; skipping IIS configuration.
2013-02-20 17:08:36 DEBUG Looking for PowerShell scripts named PostDeploy.ps1
2013-02-20 17:08:36 DEBUG No scripts with a .ps1 extension were found.
2013-02-20 17:08:36 DEBUG No scripts ending with PostDeploy.ps1 were found.
2013-02-20 17:08:36 DEBUG Looking for PowerShell scripts named PostDeploy.ps1
2013-02-20 17:08:36 DEBUG No scripts with a .ps1 extension were found.
2013-02-20 17:08:36 DEBUG No scripts ending with PostDeploy.ps1 were found.
2013-02-20 17:08:36 DEBUG Looking for PowerShell scripts named DeployFailed.ps1
2013-02-20 17:08:36 DEBUG No scripts with a .ps1 extension were found.
2013-02-20 17:08:36 DEBUG No scripts ending with DeployFailed.ps1 were found.
2013-02-20 17:08:36 DEBUG Storing a record of the deployment.

Is there anyway of increasing the logging level?

Cheers
Steve

Steve_H · 21 February 2013 10:03

Some more information.

I deleted the contents of D:\inetpub\Sites\Octopus and tried again (I’m using both re-download and force reinstall options) but no effect, the unzipped files were the old ones.

I deleted all the packages from D:\Octopus\Applications.Tentacle\Packages except the one I wanted and did another deploy and that did work.

This build number was 4.5.4799.

I’ve just done a new build 4.5.800 and did a new deploy. It created a folder for the new deployment D:\Octopus\Applications\UAT\www.enterprisestudy.com\4.5.0_13 and it unzipped 4.5.800 to it. It also deployed it correctly to D:\inetpub\Sites\Octopus.

Finally I undeleted the files from the D:\Octopus\Applications.Tentacle\Packages folder and tried to deploy 4.5.801. This time it deployed an older version.

Conclusion

So it looks like the tentacle is picking up the wrong package file when there are too many in D:\Octopus\Applications.Tentacle\Packages.

Steve_H · 21 February 2013 10:17

I’m still having no luck. It’s now deploying a different version plucked at (seemingly) random.

Thought:
What is the relationship between the build number of the .dll (the version number of one of many DLL’s in the package for all Octopus knows) and the version number in the nuspec file?

If it’s the version number in the nuspec file, how can I update that automatically from the build?

We’re using VB.Net.

Paul_Stovell · 21 February 2013 10:39

Hi Steve,

It’s very important when creating NuGet files to always increment the package version before building the NuGet package. Octopus caches packages and uses the version numbers to know if a package has been installed already. If the package always has the same version, we’d never be able to cache it or know if we’d installed it. That’s why you’re seeing the behavior above.

Octopus doesn’t have any relationship with the AssemblyInfo version numbers, because a package could contain many assemblies. That’s why we rely on the package version number.

How are you creating your NuGet package? If you are using OctoPack, OctoPack can automatically set the package version number based on your assembly info file. If you are packaging it yourself using NuGet.exe, you can pass the -Version parameter to specify a version number (e.g., -Version 2.0.1).

Paul

Steve_H · 21 February 2013 12:03

Hmm,
First problem was that Octopack requires that the Package element looks like this:

<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">

Otherwise you get an exception. The file generated by nuget isn’t compatible.

Second problem is how do you get the build parameters into the VS UI. msbuild calls them Project level properties - what are they? If I use MSbuild it works - but we don’t.

Now that I’ve done that it is bulding a new package for every new build but now I’ve got a problem with Releases.

We’re working towards release 4.5. I want to include all builds from the build environment, ie 4.5.* whenever I hit deploy.

Now that I’m getting a different nuspec version for every build Octopus is expecting me to generate a new release for every build as well.

May be I’m missing something, but that doesn’t seem right. The outside world wants to see incrementing build numbers but internally we will need to build a few times before we have a release candidate.

Equally I don’t want to have manually configure a new release and deployt it - that’s not automation, well it’s not one click anyway.

How should we handle that?

Steve_H · 21 February 2013 14:53

Hi,

OK, Octo seems to be automating a lot of that now.

I think it would have helped me a lot if Octo and Octopack were portrayed as being pretty much essential components of Octopus Deploy, rather than advanced tools.

Now to get the .config files working…

Thanks

S.