hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vihang Karajgaonkar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-19077) Handle duplicate ptests requests standing in queue at the same time
Date Fri, 13 Apr 2018 19:24:00 GMT

    [ 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)

Mime
View raw message