[devel] Q: Do not EPERM test-only tasks

[Denis Medvedev]

On 12/3/20 10:27 PM, Dmitry V. Levin wrote:
> On Thu, Dec 03, 2020 at 10:16:53PM +0300, Dmitry V. Levin wrote:
>> On Thu, Dec 03, 2020 at 10:04:02PM +0300, Vitaly Chikunov wrote:
>>> On Thu, Dec 03, 2020 at 09:51:09PM +0300, Dmitry V. Levin wrote:
>>>> On Thu, Dec 03, 2020 at 09:30:00PM +0300, Vitaly Chikunov wrote:
>>>>> On Thu, Dec 03, 2020 at 09:26:34PM +0300, Dmitry V. Levin wrote:
>>>>>> On Thu, Dec 03, 2020 at 09:14:02PM +0300, Vitaly Chikunov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Предлагаю test-only таски не переводить в состояние EPERM. Это позволит
>>>>>>> легко отличить в почте результат run --test-only от run --commit!
>>>>>> А в какое состояние тогда их переводить?
>>>>> Варианты: TESTED, TESTEPERM,
>>>> Я не понял, что предлагается, убрать acl check из test-only tasks?
>>> Я не предлагал вариантов как это реализовать.
>>>
>>>> Или игнорировать результат acl check для test-only tasks?
>>>>
>>>> Я пока не понял, что именно не устраивает в нынешней ситуации.
>>>> Задания в состояние EPERM, которые test-only, явно помечены как test-only.
>>> Да, но все равно это путает. Почему-то у меня EPERM оверрайдит test-only
>>> в голове. Впрочем, если считаешь, что пользы от этого нет то ОК, для
>>> этого и обсуждение.
>> Допустим, это путает, а какой вариант будет путать меньше?
>>   
>> Если acl check будет происходить после того, как задание (не важно,
>> test-only или нет) оказалось в состоянии TESTED, это будет удобнее?
>>    
>> Условно говоря, BUILDING -> TESTED -> CHECKPERM -> PENDING|EPERM
>> (где CHECKPERM - это некое новое промежуточное, не обязательно видимое
>> состояние)?
> Допустим, test-only задание находится в состоянии TESTED, и автор этого
> задания делает ему task run --commit, в результате чего задание переходит
> в состояние EPERM.  Вопрос, какие уведомления по каким адресам и с каким
> содержанием рассылать в этой ситуации?
>
Два варианта из жизни

1)разработчик сделал тестовое задание

и оно собралось в EPERM.

Дальше он просит администратора бранча его подтвердить и запустить.

Но администратор не может - он не в состоянии запустить EPERM задание

которое TEST-ONLY хотя выглядит оно точно также и для разработчика и для 
администратора.

Я бы различал EPERM тестированного и не тестированного задания как-то. 
Или вообще не вешал бы

EPERM на TESTED задания, ограничиваясь информацией в логах сборки.

2) разработчик сделал тестовое задание, которое в принципе не собирается 
коммитить в бранч.

Тогда EPERM  для него не несет никакой информации, а просто раздражает 
своим отличием от таких

же заданий в состоянии TESTED. Такое может быть нужно, к примеру, для 
сборки пользовательского софта

для целей тестирования на собираемость в условиях сборочницы.