> 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.