eir patches
>>> >>
>>> >> 2: *Add a safety switch* to this queue checking feature
>>> (currently proposed
>>> >> in HIVE-19077), deduplication can be switch off on request
>>> >> pros: same as 1st,
if they
>>> >> amend their patches
>>> >>
>>> >> 2: *Add a safety switch* to this queue checking feature
>>> (currently proposed
>>> >> in HIVE-19077), deduplication can be switch off on request
>>> >> pros:
Vihang Karajgaonkar created HIVE-19507:
--
Summary: Ptest queue size is 5 which doesn't make any sense
Key: HIVE-19507
URL: https://issues.apache.org/jira/browse/HIVE-19507
Project:
Vihang Karajgaonkar created HIVE-19426:
--
Summary: Move the Ptest queue to Ptest server
Key: HIVE-19426
URL: https://issues.apache.org/jira/browse/HIVE-19426
Project: Hive
Issue Type
;> mechanism i.e.
>> >> turn it off for big/urgent patches
>> >> cons: big patches that use the swich might still waste resources,
>> also devs
>> >> might use safety switch inappropriately for their own evil benefit
>> :)
>> >>
>
gt; :)
> >>
> >> 3: Deduplication the other way around - *only the first queued job
> will run
> >> of the same jira*, ptest server will keep record of patch names and
> won't
> >> execute a patch with a seen name and jira number again
>
>> 3: Deduplication the other way around - *only the first queued job will
run
>> of the same jira*, ptest server will keep record of patch names and won't
>> execute a patch with a seen name and jira number again
>> pros: same patches will not be executed m
he first queued job will run
>> of the same jira*, ptest server will keep record of patch names and won't
>> execute a patch with a seen name and jira number again
>> pros: same patches will not be executed more times accidentally, big
>> patches won't be a problem e
name and jira number again
> pros: same patches will not be executed more times accidentally, big
> patches won't be a problem either, devs will get their ptest result back
> earlier even if more jobs are triggered for same jira/patch name
> cons: scheduling is less fair: devs c
on't be a problem either, devs will get their ptest result back
earlier even if more jobs are triggered for same jira/patch name
cons: scheduling is less fair: devs can reserve their spots in the queue
(0: restore original: I'm strongly against this, ptest queue is already too
big as
Would it be possible to add patch name validation when it gets added to the
queue?
Currently I think it fails when the bot gets to the patch if it’s not named
correctly.
More common for branch patches
On 4/20/18, 8:20 AM, "Zoltan Haindrich" wrote:
Hello,
Some time ago
Hello,
Some time ago the ptest queue worked the following way:
* for some reason ATTACHMENT_ID was not set by the upstream jira scanner
tool; this triggered a feature in Jenkins: if for the same ticket
mutliple patches were uploaded; they didn't triggered new runs (because
the param
12 matches
Mail list logo
