I’ve come across an interesting issue when launching a grunt script via powershell inside a Octopus project, which seems to be related (although I didn’t do a lot of experimentation yet) to the way either Octopus or grunt handle writing to the standard output (or at least this is where the analysis brought me thus far).
The issue does not appear when running the same powershell script outside Octopus and it manifests in this way: as soon as I execute the first grunt.log.writeln statement inside my grunt script, the whole Octopus project exits with exit code 1. No further details are printed, regardless of what the actual grunt script does after the first call to grunt.log.writeln. If I comment the first use of such statement the script continues until the very next call to grunt.log.writeln, and exhibits the same behavior, in a totally reproducible way.
I know this may sound quite awkward, any idea why this might be happening?
Thanks for getting in touch. I’m not exactly aware of the Grunt case, but we’ve seen many scenarios where users had problems executing console processes that can exclusively run on interactive mode. Sometimes these processes didnt seem to need to run on interactive mode, like selenium, but in the end they couldnt be executed by a service running under a user account that is not actually logged into the server.
We’ve heard of users that were able to workaround this by creating a scheduled task that executes their command line scripts, and they just executed the task from Octopus.
I know this isn’t a solution, but i hope it helps somehow!
For anyone coming across this issue, the problem is a bug in node itself (thus showing up in grunt as well), and the solution is to use grunt.util.exit rather than process.exit from within the grunt script. It has to do with buffering of output and error streams in Windows.