[
https://issues.apache.org/jira/browse/YETUS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012678#comment-16012678
]
Allen Wittenauer commented on YETUS-507:
----------------------------------------
Actually, I pretty sure Yetus already handles this case for JIRA (and maybe
Bugzilla).
If you dig through jira_locate_patch, you'll run across this code:
{code}
if [[ ! ${PATCHURL} =~ \.patch$ ]]; then
guess_patch_file "${fileloc}"
if [[ $? == 0 ]]; then
yetus_debug "The patch ${PATCHURL} was not named properly, but it looks
like a patch file. Proceeding, but issue/branch matching might go awry."
add_vote_table 0 patch "The patch file was not named according to
${PROJECT_NAME}'s naming conventions. Please see ${PATCH_NAMING_RULE} for
instructions."
else
# this definitely isn't a patch so just bail out.
return 1
fi
fi
{code}
If the file downloaded doesn't end in .patch, Yetus attempts to figure out if
it is just a misnamed patch file. guess_patch_file does some "fancy
heuristics" (haha) to see if it really is. If it isn't, then we just leave.
At this point, JIRA is no longer considered a possible target to get the patch
and Yetus moves on. Eventually it will end all of the ways it knows about and
end up here:
{code}
if [[ ! -f "${PATCH_DIR}/patch"
&& -f "${patchfile}" ]]; then
cp "${patchfile}" "${PATCH_DIR}/patch"
if [[ $? == 0 ]] ; then
echo "Patch file ${patchfile} copied to ${PATCH_DIR}"
else
yetus_error "ERROR: Could not copy ${patchfile} to ${PATCH_DIR}"
cleanup_and_exit 1
fi
fi
{code}
In other words, if Yetus still doesn't have a valid patch file, it will print
to the console that it doesn't know how to deal with whatever input it received
and bail. It does not report that to JIRA, Github, or any other configured bug
systems.
This is a stark contract to the pre-Yetus version of test-patch that would yell
about everything. ;)
> 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)
