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