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 <[email protected]> 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 <[email protected]>
> wrote:
>
>>
>>> On Sep 28, 2016, at 7:24 AM, Casey Brotherton <[email protected]>
>> 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>
