I am working on some build scripts that get run on TFS. During the build process I need to check in the changes that where done during the build process (A set of binaries other projects depend on).
I would really like to leave the option "Fail on Standard Error" enabled for the script, however my push keeps writing to standard error even though I told it not to.
The line I do is:
git push -q binaryRepo HEAD:"$Env:BUILD_SOURCEBRANCH"
remote: Analyzing objects... (3/3) (657 ms)
remote: Storing packfile... done (40 ms)
remote: Storing index... done (42 ms)
2016-10-28T20:05:32.4019436Z ##[error]Process completed with exit code 0 and had 1 error(s) written to the error stream.
2016-10-28T20:05:32.4029436Z ##[debug]System.Exception: Process completed with exit code 0 and had 1 error(s) written to the error stream.
Anything prefixed with
remote: is spit out not by your Git, but rather by the other Git, the one you're pushing-to.
There's no built-in way to shut up the other Git. You could find out what sort of pre-receive and update hook they1 have set up—these hooks, or the things they invoke, are what are printing
Analyzing objects and so on—and see if they have provided a "quiet" flag, and if so, whether they have also provided some way for you to set that flag.2 If not, you are stuck: you must either discard stderr output entirely, or ignore it (which amount to the same thing). You can trust that if your Git prints some important failure message, it will exit with a nonzero status: that's something you can control (by fixing your own Git if necessary, or switching to another version), while "things done on the remote" are generally something you cannot control.
1It sounds like "they" are in fact you, which means you're in luck! Just stand over on the other, server, side, where you're doing these scripts, and see footnote 2.
2Due to a lack of exposed side channels, there's no easy and convenient, yet universal, way to set flags. If you're using
ssh:// as your protocol, you can use
$HOME/.ssh/environment to pass extra environment variables, provided that their sshd permits this. That's a bit clumsy, and obviously does not work at all if you are using
Another method that will work in theory—I've never tried it in practice—is to have an agreed-upon, always-force-push-able, dummy branch or tag name. This cannot be used with an
update hook, but a
pre-receive hook could scan athrough all the proposed updates, and if the special branch or tag is included, use its presence and/or its target object to provide the smuggled data (e.g., flags for the remaining pre-receive branch actions).