[ 
https://issues.apache.org/jira/browse/YETUS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16013205#comment-16013205
 ] 

Allen Wittenauer commented on YETUS-507:
----------------------------------------

bq. I was under the impression that we had still kept the test-patch behavior 
of complaining as loud and as often as possible.

Well, sort of.  The console still yells about quite a few things.  However the 
decision to not clog up the bug reporting systems with info like this was made 
very early on.  By using the two together, the general thinking is that if 
someone submits something that theoretically should work, they can always hop 
onto the console/look at the console log to see if test-patch rejected it for 
'non-patch' (or whatever) reasons.   

>From what I've seen, this approach seems to be mostly working.  User uploads a 
>patch + support material  (in that order) in one shot.  test-patch grabs the 
>support material (last-in wins) and quietly exits.  User looks at console log 
>to see that it didn't grab the patch... at that point, users split into two 
>camps: confusion or recognition that the last thing uploaded matters, with 
>most people being in the latter category.

Thanks for the input [~mdrob]! I'll go ahead and close this out.  I'm not even 
sure what to dupe this as since it's been in the code base for a while. lol

> Add option to suppress output if patch detection fails
> ------------------------------------------------------
>
>                 Key: YETUS-507
>                 URL: https://issues.apache.org/jira/browse/YETUS-507
>             Project: Yetus
>          Issue Type: Improvement
>          Components: Test Patch
>            Reporter: Mike Drob
>
> I'd like to be able to use Yetus with a JIRA workflow that doesn't have a 
> Patch Available state. This means that I'll be looking at all attachment 
> updates as they come in, some of which will be patches, but others will be 
> screenshots, logs, etc.
> Instead of downloading the latest attachment, figuring out what it is, and 
> then potentially triggering Yetus, I'd like to be able to delegate that to 
> Yetus since I think it already has that logic (and would be doing patch 
> detection anyway). Then, when an attachment fails patch detection, I'd like 
> Yetus to fail silently instead of updating the JIRA with a -1 precommit 
> check. There's no reason to post an update when somebody gives me a 
> screenshot, and the -1 would likely confuse people more than it would help on 
> the true patch apply failures.
> This should be a configurable option that is off by default.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to