I’m seeing some strange behaviour when running Powershell/Azure Powershell commands during a deployment process. For example when using script console or local to execute Get-ChildItem it returns:
However, during a deployment process the same command results are output as follows:
I just updated Octopus Server this morning to v2020.6 (Build 4915) although it was the same behaviour on the previous version we were running (I don’t have that recorded). We are also running Octopus on Windows Server Core.
The step is an Azure Powershell step however, I’m seeing the same with just Powershell
Are you trying to get the directory information for C:\Octopus\Work\################ or C:\Octopus? If you are trying to get the former, you don’t need to do anything extra other than Get-ChildItem. If you are trying to get the latter, you do cd .. 2 times rather than the Set-Location command.
Can you give either of those a try depending on what your use case is and let me know if it works?
Regarding the newline, I believe we trim any blank lines when writing to the log to preserve space. In my testing, Write-Host " " (with a space in between) worked for me, but it does leave a space character in your log. I’m not sure if that will mess up any external parsing you have setup or if this is purely for aesthetics.
Please let me know what you think, and how the testing on your Get-ChildItem goes.
Thanks for the tip for Write-Host. Do you know why Write-Host "<BACKTICK>n" doesn’t work for a new line in Octopus when it does for native powershell?
The moving of location was to ensure I was in the referenced package when I run Get-ChildItems but what I’m really looking for is why my output for Get-ChildItem is different to yours (which is what I was hoping for)?
Thanks for the tip for Write-Host. Do you know why Write-Host “n” doesn’t work for a new line in Octopus when it does for native powershell?
This is due to how Octopus does its logging. To save space, we get rid of newlines. It technically is working inside the PowerShell instance that’s running the deployment, but the newline is not getting transferred to the log.
The moving of location was to ensure I was in the referenced package when I run Get-ChildItems but what I’m really looking for is why my output for Get-ChildItem is different to yours (which is what I was hoping for)?
When you do just Get-ChildItem with no Set-Location, does it output the work directory correctly?
If so, we can change the directory using system variables to the directory of the extracted package.
You can try with:
cd "#{Octopus.Action[StepName_Where_The_Package_Got_Deployed].Output.Octopus.Action.Package.InstallationDirectoryPath}"
Get-ChildItem
Can you please let me know if I explained that okay and if it works for you?
I have run a script similar to yours but the output for the Get-ChildItem is the same.
Write-Host $OctopusParameters[“Octopus.Action.Package[MyPackage].ExtractedPath”]
cd $OctopusParameters[“Octopus.Action.Package[MyPackage].ExtractedPath”]
Get-ChildItem
I’ll PM you a screenshot of the output.
I’m not sure if itis relevent but I am running the script on the Server rather than a deployment tentacle or worker.
Depending on how you have your process and server/tentacle setup, it likely will not work to run that command on the server if the package is being extracted on a tentacle. You would need to run it on the tentacle to get to the path.
Can I please ask what the high level use case is you’re trying to achieve here? Maybe we can attack this from a different angle.
The deployment process should be entirely run on the server, so didn’t think tentacles would be involved.
Essentially, (all on the server) I wanted to extract the package and run Get-ChildItem on the contents. I’m less bothered about been in the correct directory to achive the list and more around the output from Get-ChildItem. I would expect an outcome like your image a path, a concise list of items within the directory, however, as you can see from my screenshot I get really verbose output. When I do the same thing in the script console the verbose output is not used, it matches your output.
I was able to reproduce your results in a Azure Script Step, but regular Script Steps worked normally.
I’m going to have a conversation with our developers regarding this, but in the meantime, depending on what you want to do with the Get-ChildItem, you may be able to do it with a workaround.
$Obj = Get-ChildItem
foreach ($item in $Obj){
Write-Host $item
}
This resulted in outputting the folder names and items within the current directory. You could implement logic to work with those items as well but I didn’t do a lot of testing beyond that as I wasn’t sure what your use case was.
Please let me know if you think that workaround will do for now while I get developer input.
Thanks for your patience in looking into this for me and I appreciate you raising it to the developers. It isn’t a major thing but one of those niggles that cause the log output to be convoluted.
I have also been using Get-ChildItem -Name as a workaround which just prints out the names of files and directories which I think will do something similar to your loop.
