In the latest version I am experiencing various problems with the basedir/location.
Now, custom powershell scripts are executed using the basedir/location of the powershell installation. So when I now write “Write-Host $(get-location)” in a custom script I get the following location:
“C:\Windows\System32\WindowsPowerShell\v1.0”
Previously I would get the path to which the package had been deployed. So now I have to write the following to execute stuff in the deployment dir: $OctopusParameters[‘OctopusOriginalPackageDirectoryPath’] + "\sample.exe’. Previously I could just write “sample.exe”.
The same goes for the physical path of IIS deployments. Previously that would be set to the path to which the package had been deployed. Now it is also set to “C:\Windows\System32\WindowsPowerShell\v1.0” (see attached screenshot). The only way to avoid this seems to be to assign a custom installation directory. When I do that the path is set correctly.
I am running v2.3.3.1369 on the server and all tentacles. The tentacle is a Windows Server 2012 DataCenter edition.
We made some significant changes here in 2.3 so I’m confident you’ve found a blind-spot of ours, but I’m having a lot of trouble replicating it (I’m concentrating on the first item, the incorrect working directory observation).
Is it possible you could attach or send to our support@ address the “Raw” task log for a broken deployment?
If you can create a fresh deployment log with the OctopusPrintEvaluatedVariables variable set to True that might give us some extra info, but either that or an existing log would be a big help.
One other thought Lars - is the behaviour consistent on multiple Tentacles? A corrupted DeploymentJournal.xml file could explain this somehow, but if so I’d expect the behaviour to be specific to a single machine.
Yes, the behaviour consistent on all Tentacles?. But they have all gone through the same tentacle upgrade process so maybe that is what has caused it. I have sent the logs along with the DeploymentJournal.xml file to your support mail.
Thanks for sending those through, unfortunately we haven’t turned anything up. Can you please increase the logging level on Tentacle to Trace: info is at http://docs.octopusdeploy.com/display/OD/Log+files
I’m sorry about the time this is taking - thanks for your patience.
I have been away for the last week so sorry for the delay. I have just retried the issue and can now for the life of me not reproduce it. I have gone through the update log on the servers and no patches has been deployed since we encountered the issue…
However I was able to reproduce the second (WebSite) issue. I have attached the log.
Ok, not much to go on from the log unfortunately. There is an issue in 2.3.3 that can mask earlier failures, causing them to show as warnings rather than errors. If this is triggered, the affected nodes will be shown in orange; I don’t suppose there are any of these in this case?
We may need to create a specially-instrumented version of the code to track this down. I’ll keep at it for now and let you know.
Can you add me to Skype (paulstovell) or let me know another screen-sharing technology that works for you? I’d like to track this down - being able to see your screen might help to uncover what is going on.
Right now the US west coast, but on Monday I’ll be in QLD, Australia time. If you like you can add me to Skype and just say Hi when you’re available and we’ll see if it overlaps. Otherwise email me some times/days that work for you and I’ll make myself available (paul at octopusdeploy.com)
