[
https://issues.apache.org/jira/browse/HIVE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437783#comment-16437783
]
Vihang Karajgaonkar commented on HIVE-19077:
--------------------------------------------
I think instead of not running the build we should remove the already scheduled
build since ptests always uses the latest version of the attached patch. The
problem with this approach is though dev can "reserve" their spot in the queue
before the patch is ready and then work on the patch so that it is gets tested
sooner. [~djaiswal] just to understand your issue is the problem happening
because you attach a higher version of patch after rebasing? What happens if
you re-attach the patch with the same version number since that seems to be
what you intend to do, right? That way it will not be added to the queue again
right?
> 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.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)
