Re: [DISCUSS]: Debug logging for submitted patches from contributors.

[Casey Brotherton <cb...@cloudera.com>]

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 <aw...@effectivemachines.com>
wrote:

>
> > On Sep 28, 2016, at 7:24 AM, Casey Brotherton <cb...@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>

Re: [DISCUSS]: Debug logging for submitted patches from contributors.

[Allen Wittenauer <aw...@effectivemachines.com>]

	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 <cb...@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 <aw...@effectivemachines.com>
> wrote:
> 
>> 
>>> On Sep 28, 2016, at 7:24 AM, Casey Brotherton <cb...@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>