I just remembered that I used this trick elsewhere. Take a look at the builtin-bugsystem's console report file. Those weird exec's are redirecting stdout to file descriptors. We'll likely have to redo that code if we do this globally. :)
> On Oct 4, 2016, at 9:01 AM, Casey Brotherton <cbrother...@cloudera.com> wrote: > > I like #3, I will see if I can mark out some time this week to try it. > > yetus_* logging should be easy to send to a file. > > > On Thu, Sep 29, 2016 at 4:03 PM, Allen Wittenauer <a...@effectivemachines.com> > wrote: > >> >>> On Sep 28, 2016, at 7:24 AM, Casey Brotherton <cbrother...@cloudera.com> >> wrote: >>> >>> Hello, >>> >>> Over the past couple of months, I have submitted a couple of small >> patches, >>> and hope to add larger contributions. >> >> I hope you and others know that you're making me feel extremely >> guilty that I haven't had a chance to work on some of my open issues. :p >> >>> When a patch is submitted to the YETUS jira component, within the next >> five >>> minutes, jenkins will use the newly uploaded YETUS patch on the YETUS >> repository. >> >> *fingers crossed* :) >> >> But yeah, precommit is supposed to be smart enough to know when it >> is going to patch itself or things it relies upon to execute, e.g. a >> Dockerfile. Folks should know that there are a couple of edge cases where >> this doesn't really work as intended. One of the key ones is if docker >> mode is turned on and a patch touches the re-exec functionality. It only >> ever re-exec's itself once so that code isn't really patch tested. >> (Luckily, that code is rarely touched.) >> >>> There is not currently a local unit test for jira integrations. >> >> Correct. FWIW, I've got an issue open over in hadoop that I use >> for all my testing. Hadoop's build is insanely complex so in general, it >> acts as a pretty good sounding board for certain changes. >> >>> Does the suggestion to allow non-committers to see debug output make >> sense? >> >> I can see the value in this, for sure. >> >>> Is there a #3 that I missed? >> >> Yes, I think so, but it's going to take some investigation: >> >> If precommit detects that it is being patched, it optionally can >> be configured to run in a mode that sends stdout and stderr to a log file. >> (stdout still only goes to the screen.) The log file that is created is >> then added to the table to provide a link to where JIRA, GH, etc, users can >> see it. This solves some of the problems you highlighted for your #1 and >> #2 solutions. >> >> I have it in my head that this be accomplished with some simple >> exec + redirection + tee combos in the re-exec code, but someone would need >> to test the hypothesis out further. >> >> > > > -- > Casey J. Brotherton > Customer Operations Engineer > [image: www.cloudera.com] <http://www.cloudera.com>