yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@effectivemachines.com>
Subject Re: [DISCUSS]: Debug logging for submitted patches from contributors.
Date Thu, 29 Sep 2016 21:03:28 GMT

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


Mime
View raw message