In the mean time, you could use New-OctopusArtifact to attach the file as an artifact, which you can then view from your browser:
(See Collecting Artifacts here: http://docs.octopusdeploy.com/display/OD/Script+Console)
I like this suggestion. It should also be settable within deployment scripts - e.g.,
write-host '##octopus[quality dimension="tests" value="3"]'
Thanks everyone who provided feedback on this ticket. We published a blog post yesterday showing how to do PowerShell DSC with Octopus – everything from deploying DSC scripts, detecting drift, getting email notifications when drift occurs, and automatically fixing the drift:
With that in mind, I think many of the comments on this suggestion are “done”. But there might be some areas of DSC support that we still don’t do. I’d really appreciate if you could read the post, and let us know of any scenarios we’ve missed. If it looks like we’ve done nearly everything, I might close this UserVoice suggestion and we can open new, more targeted suggestions for any gaps.
We’ll be building this very soon
When we find a Web.Release.config file, there's usually a Web.config file.
What would happen if your package had:
Which file(s) would the App.Release.config transform run against?
Another way to approach this may be queues:
I think we show the Octopus-side of the logs in local time while the Tentacle times are in GMT. In Octopus 2.0 we'll have this all sorted.
Hi Matthew, what scenario/benefit would XML unlock that JSON can't currently handle?
For C# consumers we plan to ship a NuGet package that wraps the API so that you won't need to deal with the JSON directly.