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>
