[
https://issues.apache.org/jira/browse/HIVE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446707#comment-16446707
]
Adam Szita commented on HIVE-19077:
-----------------------------------
[~kgyrtkirk] - yes that would be ideal, however that would require a change in
Precommit-Admin job so I wouldn't take that direction.
[~djaiswal] - I've been thinking about the size sensitive solution you
suggested. I think we should not depend on it, it will kind of create a mess,
people will not be able to follow why a certain job was skipped or not, and
also patch size might not be a good enough heuristic to be used for such
decisions.
I would still suggest the Jira text (tag) option, as IMO it would be very clear
that if it's set, we skip checking the queue, if not (which is default) queue
will be checked. It is also not a new way of toggling options on precommit
test, as the [NO PRECOMMIT TESTS option already
exists|https://cwiki.apache.org/confluence/display/Hive/Hive+PreCommit+Patch+Testing].
That said I've put together a [patch|^HIVE-19077.overrideoption.patch] with
these changes:
* if the text SKIP PRECOMMIT QUEUE CHECK can be found on a Jira, the queue
check will be skipped
* modified error handling so that the HTTP 502 error and any other failures
are swallowed
> Handle duplicate ptests requests standing in queue at the same time
> -------------------------------------------------------------------
>
> Key: HIVE-19077
> URL: https://issues.apache.org/jira/browse/HIVE-19077
> Project: Hive
> Issue Type: Improvement
> Components: Testing Infrastructure
> Reporter: Adam Szita
> Assignee: Adam Szita
> Priority: Blocker
> Fix For: 3.1.0
>
> Attachments: HIVE-19077.0.patch, HIVE-19077.1.patch,
> HIVE-19077.overrideoption.patch, HIVE-19077.sslFix.patch
>
>
> I've been keeping on eye on our {{PreCommit-HIVE-Build}} job, and what I
> noticed that sometimes huge queues can build up, that contain jira's more
> than once. (Yesterday I've seen a queue of 40, having 31 distinct jiras..)
> Simple scenario is that I upload a patch, it gets queued for ptest (already
> long queue), and 3 hours later I will update it, re-upload and re-queue. Now
> the current ptest infra seems to be smart enough to always deal with the
> latest patch, so what will happen is that the same patch will be tested 2
> times (with ~3 hours) diff, most probably with same result.
> I propose we do some deduplication - if ptest starts running the request for
> Jira X, then it can take a look on the current queue, and see if X is there
> again. If so, it can skip for now, it will be picked up later anyway.
> In practice this means that if you reconsider your patch and update it, your
> original place in the queue will be gone (like as a penalty for changing it),
> but overall it saves resources for the whole community.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
