[devel] Промежуточные сабтаски в сборочных заданиях

[devel] Промежуточные сабтаски в сборочных заданиях

[Ajrat Makhmutov]

Привет всем! Предлагаю добавить новый формат сабтасков: промежуточные 
сабтаски.

Промежуточные сабтаски- это сабтаски с пакетами более низких версий, 
которые косвенно или прямо нужны для сборки этого же пакета более 
высокой версии из этого же таска и которые при коммите задания не 
попадают в репозиторий. Под "косвенно" имею ввиду при сборке кольцевых 
зависимостей.
Такое изменение значительно упростит поддержание и отправку в стабильные 
репозитории пакеты, которые зависят от себя же, и пакеты с кольцевыми 
зависимостями.

Ответ от @glebfm: "Но мой пойнт в целом в том, что это большой хак, 
который к тому же предполагает сильное переписывание сборочницы".

Как это будет работать на примере с rust: Сейчас в p10 версия 1.75.0, в 
сизифе 1.82.0.Добавляем в задание: #100 - rust-1.76.0-alt1, #200 - 
rust-1.77.0-alt1, #300 - rust-1.78.0-alt1, #400 - rust-1.79.0-alt1, #500 
- rust-1.80.0-alt1, #600 - rust-1.81.0-alt1, #700 - rust-1.82.0-alt1. 
Сабтаски с номерами 100-600 не попадают в репозиторий и являются 
промежуточными, сабтаск #700 успешно отправляется в репозиторий.

Пример с кольцевой зависимостью модулей lua: у busted, фреймворка для 
тестирования, есть runtime зависимость penlight, для тестирования 
penlight нужен busted. Добавляем в задание: #100 - penlight-1.14.0-alt1 
(без %check), #200 - busted-2.2.0-alt1, #300 - penlight-1.14.0-alt2.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Fri, 1 Nov 2024 18:46:08 +0300
Ajrat Makhmutov <ajratma@basealt.ru> пишет:

> Привет всем! Предлагаю добавить новый формат сабтасков: промежуточные 
> сабтаски.
> 
> Промежуточные сабтаски- это сабтаски с пакетами более низких версий, 
> которые косвенно или прямо нужны для сборки этого же пакета более 
> высокой версии из этого же таска и которые при коммите задания не 
> попадают в репозиторий. Под "косвенно" имею ввиду при сборке кольцевых 
> зависимостей.
> Такое изменение значительно упростит поддержание и отправку в стабильные 
> репозитории пакеты, которые зависят от себя же, и пакеты с кольцевыми 
> зависимостями.
> 
> Ответ от @glebfm: "Но мой пойнт в целом в том, что это большой хак, 
> который к тому же предполагает сильное переписывание сборочницы".

  Тут недавно прошла инфа о том, что у нас с <год>.<месяц> появилась
возможность запускать hasher внутри hasher. Если на сборочнице это
поддерживается то, возможно, удастся организовать что-то вроде
вложенной сборочницы в рамках одного сабтаска. Однако я не имею в виду,
что в примере ниже все версии rust следует упаковать в один SRPM. Тут,
конечно, нужен какой-то более гибкий подход, не оставляющий таких
чудовищных следов в истории сборок пакета.


> Как это будет работать на примере с rust: Сейчас в p10 версия 1.75.0, в 
> сизифе 1.82.0.Добавляем в задание: #100 - rust-1.76.0-alt1, #200 - 
> rust-1.77.0-alt1, #300 - rust-1.78.0-alt1, #400 - rust-1.79.0-alt1, #500 
> - rust-1.80.0-alt1, #600 - rust-1.81.0-alt1, #700 - rust-1.82.0-alt1. 
> Сабтаски с номерами 100-600 не попадают в репозиторий и являются 
> промежуточными, сабтаск #700 успешно отправляется в репозиторий.
> 
> Пример с кольцевой зависимостью модулей lua: у busted, фреймворка для 
> тестирования, есть runtime зависимость penlight, для тестирования 
> penlight нужен busted. Добавляем в задание: #100 - penlight-1.14.0-alt1 
> (без %check), #200 - busted-2.2.0-alt1, #300 - penlight-1.14.0-alt2.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Ivan A. Melnikov]

On Fri, Nov 01, 2024 at 06:46:08PM GMT, Ajrat Makhmutov wrote:
> Привет всем! Предлагаю добавить новый формат сабтасков: промежуточные
> сабтаски.
> 
[...]
> Такое изменение значительно упростит поддержание и отправку в стабильные
> репозитории пакеты, которые зависят от себя же, и пакеты с кольцевыми
> зависимостями.

Действительно, тут есть некое противоречие: регламент обновления
стабильной ветки предполагает определённую целостность и ценность
результата сборки для каждой таски, а в случае бутстрапа это
не всегда так.

> Ответ от @glebfm: "Но мой пойнт в целом в том, что это большой хак, который
> к тому же предполагает сильное переписывание сборочницы".

Может, возможно подойти к вопросу с другой стороны: не запихивать
все промежуточные этапы в одну задачу, а выстраивать цепочки
зависимых задач, способных использовать результаты сборки
друг друга, и закоммититься только всей пачкой (т.е. либо
все задачи из такой цепочки, либо ниодной)?

Кстати, если дать таким цепочкам имена, возможно, мы получим
очередной подход к карманам.

-- 
  wbr,
    iv m.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Fri, 1 Nov 2024 22:31:59 +0400
"Ivan A. Melnikov" <iv@altlinux.org> пишет:

> On Fri, Nov 01, 2024 at 06:46:08PM GMT, Ajrat Makhmutov wrote:
> > Привет всем! Предлагаю добавить новый формат сабтасков: промежуточные
> > сабтаски.
> >   
> [...]
> > Такое изменение значительно упростит поддержание и отправку в стабильные
> > репозитории пакеты, которые зависят от себя же, и пакеты с кольцевыми
> > зависимостями.  
> 
> Действительно, тут есть некое противоречие: регламент обновления
> стабильной ветки предполагает определённую целостность и ценность
> результата сборки для каждой таски, а в случае бутстрапа это
> не всегда так.
> 
> > Ответ от @glebfm: "Но мой пойнт в целом в том, что это большой хак, который
> > к тому же предполагает сильное переписывание сборочницы".  
> 
> Может, возможно подойти к вопросу с другой стороны: не запихивать
> все промежуточные этапы в одну задачу, а выстраивать цепочки
> зависимых задач, способных использовать результаты сборки
> друг друга, и закоммититься только всей пачкой (т.е. либо
> все задачи из такой цепочки, либо ниодной)?

  Насколько я понял, Айрат же как раз хочет только последний
результат, _без_ промежуточных. А цепочки тасков у нас и так есть,
только без возможности использования тасков в сборочных окружениях.
Если последнее реализовать, то тогда можно было бы сказать:

  $ ssh girar task new
  $ ssh girar task add N1 rust1
  $ ssh girar task run N1 --temporary

  $ ssh girar task new
  $ ssh girar task add N2 rust2
  $ ssh girar task uses N2 add N1
  $ ssh girar task run N2 --commit

  Причём, uses аналогично deps но дополнительно ещё и делает
репозиторий N1 доступным для задания N2. Опция --temporary
аналогична --test-only, но с той разницей, что после коммита
N2 в репозиторий, N1 автоматически удаляется.

  Мне кажется, что доступность репозитория задания для другого
задания сделать, всё же, легче, чем доступность сабтасков друг
для друга.


> Кстати, если дать таким цепочкам имена, возможно, мы получим
> очередной подход к карманам.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Fri, 1 Nov 2024 22:11:17 +0300
Paul Wolneykien <manowar@altlinux.org> пишет:

> В Fri, 1 Nov 2024 22:31:59 +0400
> "Ivan A. Melnikov" <iv@altlinux.org> пишет:
> 
> > On Fri, Nov 01, 2024 at 06:46:08PM GMT, Ajrat Makhmutov wrote:  
> > > Привет всем! Предлагаю добавить новый формат сабтасков: промежуточные
> > > сабтаски.
> > >     
> > [...]  
> > > Такое изменение значительно упростит поддержание и отправку в стабильные
> > > репозитории пакеты, которые зависят от себя же, и пакеты с кольцевыми
> > > зависимостями.    
> > 
> > Действительно, тут есть некое противоречие: регламент обновления
> > стабильной ветки предполагает определённую целостность и ценность
> > результата сборки для каждой таски, а в случае бутстрапа это
> > не всегда так.
> >   
> > > Ответ от @glebfm: "Но мой пойнт в целом в том, что это большой хак, который
> > > к тому же предполагает сильное переписывание сборочницы".    
> > 
> > Может, возможно подойти к вопросу с другой стороны: не запихивать
> > все промежуточные этапы в одну задачу, а выстраивать цепочки
> > зависимых задач, способных использовать результаты сборки
> > друг друга, и закоммититься только всей пачкой (т.е. либо
> > все задачи из такой цепочки, либо ниодной)?  
> 
>   Насколько я понял, Айрат же как раз хочет только последний
> результат, _без_ промежуточных. А цепочки тасков у нас и так есть,
> только без возможности использования тасков в сборочных окружениях.
> Если последнее реализовать, то тогда можно было бы сказать:
> 
>   $ ssh girar task new
>   $ ssh girar task add N1 rust1
>   $ ssh girar task run N1 --temporary
> 
>   $ ssh girar task new
>   $ ssh girar task add N2 rust2
>   $ ssh girar task uses N2 add N1
>   $ ssh girar task run N2 --commit
> 
>   Причём, uses аналогично deps но дополнительно ещё и делает
> репозиторий N1 доступным для задания N2.

  Хотя нет, не только в этом. N2 должно начать собираться в этом
случае по достижению N1 состояния TESTED, а не DONE, как сейчас
для deps.


> Опция --temporary
> аналогична --test-only, но с той разницей, что после коммита
> N2 в репозиторий, N1 автоматически удаляется.
> 
>   Мне кажется, что доступность репозитория задания для другого
> задания сделать, всё же, легче, чем доступность сабтасков друг
> для друга.
> 
> 
> > Кстати, если дать таким цепочкам имена, возможно, мы получим
> > очередной подход к карманам.  
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[ajratma]

01.11.2024 22:26, Paul Wolneykien пишет:

> В Fri, 1 Nov 2024 22:11:17 +0300
> Paul Wolneykien <manowar@altlinux.org> пишет:
>
>> В Fri, 1 Nov 2024 22:31:59 +0400
>> "Ivan A. Melnikov" <iv@altlinux.org> пишет:
>>
>>> On Fri, Nov 01, 2024 at 06:46:08PM GMT, Ajrat Makhmutov wrote:
>>>> Привет всем! Предлагаю добавить новый формат сабтасков: промежуточные
>>>> сабтаски.
>>>>      
>>> [...]
>>>> Такое изменение значительно упростит поддержание и отправку в стабильные
>>>> репозитории пакеты, которые зависят от себя же, и пакеты с кольцевыми
>>>> зависимостями.
>>> Действительно, тут есть некое противоречие: регламент обновления
>>> стабильной ветки предполагает определённую целостность и ценность
>>> результата сборки для каждой таски, а в случае бутстрапа это
>>> не всегда так.
>>>    
>>>> Ответ от @glebfm: "Но мой пойнт в целом в том, что это большой хак, который
>>>> к тому же предполагает сильное переписывание сборочницы".
>>> Может, возможно подойти к вопросу с другой стороны: не запихивать
>>> все промежуточные этапы в одну задачу, а выстраивать цепочки
>>> зависимых задач, способных использовать результаты сборки
>>> друг друга, и закоммититься только всей пачкой (т.е. либо
>>> все задачи из такой цепочки, либо ниодной)?
Промежуточные/временные задания не сделают переписывание сборочницы 
проще или хак чище, чем промежуточные сабтаски.
>>    Насколько я понял, Айрат же как раз хочет только последний
>> результат, _без_ промежуточных. А цепочки тасков у нас и так есть,
>> только без возможности использования тасков в сборочных окружениях.
Да,  промежуточные результаты не интересны. Важен конечный.
>> Если последнее реализовать, то тогда можно было бы сказать:
>>
>>    $ ssh girar task new
>>    $ ssh girar task add N1 rust1
>>    $ ssh girar task run N1 --temporary
>>
>>    $ ssh girar task new
>>    $ ssh girar task add N2 rust2
>>    $ ssh girar task uses N2 add N1
>>    $ ssh girar task run N2 --commit
>>
>>    Причём, uses аналогично deps но дополнительно ещё и делает
>> репозиторий N1 доступным для задания N2.
>    Хотя нет, не только в этом. N2 должно начать собираться в этом
> случае по достижению N1 состояния TESTED, а не DONE, как сейчас
> для deps.
>
>
>> Опция --temporary
>> аналогична --test-only, но с той разницей, что после коммита
>> N2 в репозиторий, N1 автоматически удаляется.
>>
>>    Мне кажется, что доступность репозитория задания для другого
>> задания сделать, всё же, легче, чем доступность сабтасков друг
>> для друга.

Доступность сабтасков реализована уже сейчас: сабтаски более высокого 
номера при наличии сборочной зависимости уже имеют в сборочном окружении 
сабтаски более низкого номера. Я предлагаю вообще не добавлять новые 
опции: все сабтаски пакета, которые по этому пакету не имеют 
максимальный номер, будут являться промежуточными и не попадут в 
репозиторий.

>>
>>> Кстати, если дать таким цепочкам имена, возможно, мы получим
>>> очередной подход к карманам.
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

[devel] Re: Промежуточные сабтаски в сборочных заданиях

[Sergey V Turchin]

On Friday, 1 November 2024 22:11:17 GMT+3 Paul Wolneykien wrote:

[...]
> А цепочки тасков у нас и так есть,
Нету.
У нас есть только очередь абсолютно никак не связанных между собой сборочных 
заданий. https://bugzilla.altlinux.org/51923

[...]

-- 
Regards, Sergey.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Sat, 02 Nov 2024 11:58:08 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> On Friday, 1 November 2024 22:11:17 GMT+3 Paul Wolneykien wrote:
> 
> [...]
> > А цепочки тасков у нас и так есть,  
> Нету.
> У нас есть только очередь абсолютно никак не связанных между собой сборочных 
> заданий. https://bugzilla.altlinux.org/51923

  Связанных, есть deps. Я им часто пользуюсь. Это значит, что одно
задание может ссылаться на другое и это уже есть в сборочнице.

  Также есть всем известный флаг test-only. Это значит, что есть
задания, которые проходят все тесты, формируют свой маленький
репозиторий, но не попадают в большой репозиторий.

  Мне кажется, что осталось добавить всего одну штуку и тогда
станет возможно как то, что хочет Айрат, так и то, что хочешь
ты. Эта штука --- флаг для зависимости, по которому перед сборкой
зависимого задания к нему в apt sources подключается репозиторий
задания, от которого оно зависит. Если зависимостей несколько,
то подключается несколько репозиториев. Мне кажется, эта штука
не нарушит логику работы сборочницы.

  Я предлагаю вместо слова "deps" использовать для этого слово
"uses":

  ssh girar task uses N2 add N1

  Тогда для того, чтобы получить бутстрап, N1 остаётся в состоянии
test-only, а N2 запускается с --commit. А для того, чтобы
финально собрать всю накопленную цепочку (группу), как хочешь ты, оба
задания --- N1 и N2 --- запускаются с --commit. В последнем случае
порядок сборки заданий по deps/uses также должен учитываться.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Sat, 2 Nov 2024 14:27:17 +0300
Paul Wolneykien <manowar@altlinux.org> пишет:

> В Sat, 02 Nov 2024 11:58:08 +0300
> Sergey V Turchin <zerg@altlinux.org> пишет:
> 
> > On Friday, 1 November 2024 22:11:17 GMT+3 Paul Wolneykien wrote:
> > 
> > [...]  
> > > А цепочки тасков у нас и так есть,    
> > Нету.
> > У нас есть только очередь абсолютно никак не связанных между собой сборочных 
> > заданий. https://bugzilla.altlinux.org/51923  
> 
>   Связанных, есть deps. Я им часто пользуюсь. Это значит, что одно
> задание может ссылаться на другое и это уже есть в сборочнице.
> 
>   Также есть всем известный флаг test-only. Это значит, что есть
> задания, которые проходят все тесты, формируют свой маленький
> репозиторий, но не попадают в большой репозиторий.
> 
>   Мне кажется, что осталось добавить всего одну штуку и тогда
> станет возможно как то, что хочет Айрат, так и то, что хочешь
> ты. Эта штука --- флаг для зависимости, по которому перед сборкой
> зависимого задания к нему в apt sources подключается репозиторий
> задания, от которого оно зависит. Если зависимостей несколько,
> то подключается несколько репозиториев. Мне кажется, эта штука
> не нарушит логику работы сборочницы.
> 
>   Я предлагаю вместо слова "deps" использовать для этого слово
> "uses":
> 
>   ssh girar task uses N2 add N1
> 
>   Тогда для того, чтобы получить бутстрап, N1 остаётся в состоянии
> test-only, а N2 запускается с --commit.

  Даже не так. Чтобы убедиться в том, что бутстрап сработал, нужно
будет сделать

  ssh girar task uses N2 del N1
  ssh girar task uses N2 add N2
  ssh girar task run N2

  То есть собрать N2 в своём собственном окружении, уже без N1.
Правда, для этого нужно, чтобы репозиторий try n был доступен
для try n+1. Но после сборки try n+1 его можно удалять.


> А для того, чтобы
> финально собрать всю накопленную цепочку (группу), как хочешь ты, оба
> задания --- N1 и N2 --- запускаются с --commit. В последнем случае
> порядок сборки заданий по deps/uses также должен учитываться.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Ivan A. Melnikov]

On Sat, Nov 02, 2024 at 03:18:01PM GMT, Paul Wolneykien wrote:
> В Sat, 2 Nov 2024 14:27:17 +0300
> Paul Wolneykien <manowar@altlinux.org> пишет:
> 
>   Даже не так. Чтобы убедиться в том, что бутстрап сработал, нужно
> будет сделать
> 
>   ssh girar task uses N2 del N1
>   ssh girar task uses N2 add N2
>   ssh girar task run N2
> 
>   То есть собрать N2 в своём собственном окружении, уже без N1.
> Правда, для этого нужно, чтобы репозиторий try n был доступен
> для try n+1. Но после сборки try n+1 его можно удалять.

Так точно не надо.

Одной из важных характеристик текущей модели girar
является воспроизводимость, понимаемая как возможность
взять то же самое и сделать ещё раз.

Идея догоняющей сборки опирается на неё существенным образом.

Чтобы точно завершить бутстрап достаточно добавить
в цепочку таску с ребилдом.

-- 
  wbr,
    iv m.

[devel] Re: Промежуточные сабтаски в сборочных заданиях

[Sergey V Turchin]

On Saturday, 2 November 2024 15:46:14 GMT+3 Ivan Melnikov wrote:

[...]
> > Правда, для этого нужно, чтобы репозиторий try n был доступен
> > для try n+1. Но после сборки try n+1 его можно удалять.
> 
> Так точно не надо.
> 
> Одной из важных характеристик текущей модели girar
> является воспроизводимость, понимаемая как возможность
> взять то же самое и сделать ещё раз.
> 
> Идея догоняющей сборки опирается на неё существенным образом.
> 
> Чтобы точно завершить бутстрап достаточно добавить
> в цепочку таску с ребилдом.
Это в лучшем случае. Зачастую это может быть новый релиз того же пакета.

-- 
Regards, Sergey.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Sat, 2 Nov 2024 16:46:14 +0400
"Ivan A. Melnikov" <iv@altlinux.org> пишет:

> On Sat, Nov 02, 2024 at 03:18:01PM GMT, Paul Wolneykien wrote:
> > В Sat, 2 Nov 2024 14:27:17 +0300
> > Paul Wolneykien <manowar@altlinux.org> пишет:
> > 
> >   Даже не так. Чтобы убедиться в том, что бутстрап сработал, нужно
> > будет сделать
> > 
> >   ssh girar task uses N2 del N1
> >   ssh girar task uses N2 add N2
> >   ssh girar task run N2
> > 
> >   То есть собрать N2 в своём собственном окружении, уже без N1.
> > Правда, для этого нужно, чтобы репозиторий try n был доступен
> > для try n+1. Но после сборки try n+1 его можно удалять.  
> 
> Так точно не надо.
> 
> Одной из важных характеристик текущей модели girar
> является воспроизводимость, понимаемая как возможность
> взять то же самое и сделать ещё раз.

  Погоди, это же бутстрап --- он очень трудно воспроизводим по
определению. Сборка компилятора версии N+1 проходит с
использованием компилятора версии N. Но воспроизвести эту сборку
очень не просто. Во-первых, если в спеке не было явного Requires:
X == N, то после того, как N+1 прошёл в Сизиф, его rebuild будет
собираться тоже с N+1. Во-вторых, когда бутстрап действительно
завершён, версия N может быть удалена и, рано или поздно, будет
удалена. Отсюда понятно, что единственное стабильно воспроизводимое
состояние --- это rebuild пакета с самим собой. Или я что-то не
так понимаю?

  Вон, ребята из соседнего цеха занимаются археологией Java. И вот
совершенно не похоже на "взять то же самое и сделать ещё раз". :)


> Идея догоняющей сборки опирается на неё существенным образом.
> 
> Чтобы точно завершить бутстрап достаточно добавить
> в цепочку таску с ребилдом.
> 

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Artem Semenov]

02.11.2024 16:38, Paul Wolneykien пишет:
> В Sat, 2 Nov 2024 16:46:14 +0400
> "Ivan A. Melnikov" <iv@altlinux.org> пишет:
>
>> On Sat, Nov 02, 2024 at 03:18:01PM GMT, Paul Wolneykien wrote:
>>> В Sat, 2 Nov 2024 14:27:17 +0300
>>> Paul Wolneykien <manowar@altlinux.org> пишет:
>>>
>>>    Даже не так. Чтобы убедиться в том, что бутстрап сработал, нужно
>>> будет сделать
>>>
>>>    ssh girar task uses N2 del N1
>>>    ssh girar task uses N2 add N2
>>>    ssh girar task run N2
>>>
>>>    То есть собрать N2 в своём собственном окружении, уже без N1.
>>> Правда, для этого нужно, чтобы репозиторий try n был доступен
>>> для try n+1. Но после сборки try n+1 его можно удалять.
>> Так точно не надо.
>>
>> Одной из важных характеристик текущей модели girar
>> является воспроизводимость, понимаемая как возможность
>> взять то же самое и сделать ещё раз.
>    Погоди, это же бутстрап --- он очень трудно воспроизводим по
> определению. Сборка компилятора версии N+1 проходит с
> использованием компилятора версии N. Но воспроизвести эту сборку
> очень не просто. Во-первых, если в спеке не было явного Requires:
> X == N, то после того, как N+1 прошёл в Сизиф, его rebuild будет
> собираться тоже с N+1. Во-вторых, когда бутстрап действительно
> завершён, версия N может быть удалена и, рано или поздно, будет
> удалена. Отсюда понятно, что единственное стабильно воспроизводимое
> состояние --- это rebuild пакета с самим собой. Или я что-то не
> так понимаю?
>
>    Вон, ребята из соседнего цеха занимаются археологией Java. И вот
> совершенно не похоже на "взять то же самое и сделать ещё раз". :)

Два чая этому джентельмену. 🤝

Надеюсь, я правильно отвечаю. В первый раз отвечаю в рассылке. )

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Dmitry V. Levin]

On Sat, Nov 02, 2024 at 04:46:14PM +0400, Ivan A. Melnikov wrote:
[...]
> Одной из важных характеристик текущей модели girar
> является воспроизводимость, понимаемая как возможность
> взять то же самое и сделать ещё раз.

Это не просто важная характеристика, это принцип, на котором girar построен.


-- 
ldv

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Sat, 2 Nov 2024 16:22:54 +0200
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> On Sat, Nov 02, 2024 at 04:46:14PM +0400, Ivan A. Melnikov wrote:
> [...]
> > Одной из важных характеристик текущей модели girar
> > является воспроизводимость, понимаемая как возможность
> > взять то же самое и сделать ещё раз.  
> 
> Это не просто важная характеристика, это принцип, на котором girar построен.

  Я понял, это про другую воспроизводимость. Поскольку я не занимаюсь
догоняющими сборками, то возможность и необходимость взять предыдущее
состояние репозитория (или аналогичное ему в другом репозитории) и
перейти от этого состояния к следующему --- пример экзотический.
Но вы безусловно правы, ломать это нельзя.

  Тогда, получается, что изначальное предложение Айрата довольно точное:
всё сделать в одном задании, чтобы "накатывание" задания на репозиторий
оставалось бы однозначным переходом от известного состояния репозитория
к новому. При этом Айрат хотел каким-то особенным флагом помечать
промежуточные подзадания, "которые при коммите задания не попадают
в репозиторий". Если именно это место вызывает вопросы и сложности,
то нельзя ли поступить вот так?

  $ ssh girar task new
  $ ssh girar task add repo rust 1.76.0-alt1
  $ ssh girar task add repo rust 1.77.0-alt1
  ...
  $ ssh girar task add repo rust 1.81.0-alt1
  $ ssh girar task add repo rust 1.82.0-alt1
  $ ssh girar task add deloc rust 1.81.0-alt1
  $ ssh girar task add deloc rust 1.80.0-alt1
  ...
  $ ssh girar task add deloc rust 1.76.0-alt1
  $ ssh girar task run --commit

  Предполагается, что deloc в отличие от del, воздействует на репозиторий
данного задания ("карман"), а не на целевой репозиторий (Сизиф, p11).
Естественно, что для того, чтобы сработали множественные "add repo rust",
ограничение на совпадение имени пакета нужно будет снять.

  Упрощение при таком подходе, как мне кажется, состоит в том, что если
задание успешно проходит все подзадания, то в "кармане" получается
вполне определённое, воспроизводимое (!) при новом try состояние,
определённый набор пакетов, который можно проверить на устанавливаемость,
анметы и пр. И если всё в порядке --- добавить в целевой репозиторий.
То есть в точности, как сейчас, без проверки новых условий.

  А ещё появится возможность смешного:

  $ ssh girar task new
  $ ssh girar task add repo mypackage 1.0-alt1
  $ ssh girar task add deloc mypackage 1.0-alt1
  $ ssh girar task run --commit

  Сборка такого задания могла бы завершаться весёлым
сообщением о том, что всё успешно собралось, но результат
оказался пустым.

[devel] Re: Промежуточные сабтаски в сборочных заданиях

[Sergey V Turchin]

On Saturday, 2 November 2024 21:10:33 GMT+3 Paul Wolneykien wrote:

[...]
>   А ещё появится возможность смешного:
> 
>   $ ssh girar task new
>   $ ssh girar task add repo mypackage 1.0-alt1
>   $ ssh girar task add deloc mypackage 1.0-alt1
>   $ ssh girar task run --commit
> 
>   Сборка такого задания могла бы завершаться весёлым
> сообщением о том, что всё успешно собралось, но результат
> оказался пустым.
Создать проблему и потом решать её. :-)
Не лучше ли эти deloc-и вычислять автоматически?	

-- 
Regards, Sergey.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Tue, 05 Nov 2024 09:40:53 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> On Saturday, 2 November 2024 21:10:33 GMT+3 Paul Wolneykien wrote:
> 
> [...]
> >   А ещё появится возможность смешного:
> > 
> >   $ ssh girar task new
> >   $ ssh girar task add repo mypackage 1.0-alt1
> >   $ ssh girar task add deloc mypackage 1.0-alt1
> >   $ ssh girar task run --commit
> > 
> >   Сборка такого задания могла бы завершаться весёлым
> > сообщением о том, что всё успешно собралось, но результат
> > оказался пустым.  
> Создать проблему и потом решать её. :-)
> Не лучше ли эти deloc-и вычислять автоматически?	

  Ну, мы же не хотим усложнять код сборочницы? А ещё, автоматика иногда
делает странное. А тут всё просто: встретил deloc --- удали из "кармана"
пакеты (у которых NVR SRPM совпадает с параметром). Не нашёл таких
пакетов --- выдал ошибку.

[devel] Re: Промежуточные сабтаски в сборочных заданиях

[Sergey V Turchin]

On Tuesday, 5 November 2024 12:55:53 GMT+3 Paul Wolneykien wrote:

[...]
> > Не лучше ли эти deloc-и вычислять автоматически?
> 
>   Ну, мы же не хотим усложнять код сборочницы?
Давайте вкалывать вместо роботов? ;-)

[...]

-- 
Regards, Sergey.

[devel] Re: Промежуточные сабтаски в сборочных заданиях

[Sergey V Turchin]

On Saturday, 2 November 2024 14:27:17 GMT+3 Paul Wolneykien wrote:
> В Sat, 02 Nov 2024 11:58:08 +0300
> 
> Sergey V Turchin <zerg@altlinux.org> пишет:
> > On Friday, 1 November 2024 22:11:17 GMT+3 Paul Wolneykien wrote:
> > 
> > [...]
> > 
> > > А цепочки тасков у нас и так есть,
> > 
> > Нету.
> > У нас есть только очередь абсолютно никак не связанных между собой
> > сборочных заданий. https://bugzilla.altlinux.org/51923
>   Связанных, есть deps.
Нет. Пакет из одного задания не может быть собран с devel-пакетом из другого. 
Это можно сделать только в одном задании.

>   Я им часто пользуюсь.
Я им постоянно пользуюсь.
task ls --user=zerg --state=POSTPONED

>   Это значит, что одно задание может ссылаться на другое и это уже есть в 
сборочнице.
Это просто очередь, лишь порядок определённ мантенйером.

-- 
Regards, Sergey.

Re: [devel] Промежуточные сабтаски в сборочных заданиях

[Paul Wolneykien]

В Sat, 02 Nov 2024 15:55:58 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> On Saturday, 2 November 2024 14:27:17 GMT+3 Paul Wolneykien wrote:
> > В Sat, 02 Nov 2024 11:58:08 +0300
> > 
> > Sergey V Turchin <zerg@altlinux.org> пишет:  
> > > On Friday, 1 November 2024 22:11:17 GMT+3 Paul Wolneykien wrote:
> > > 
> > > [...]
> > >   
> > > > А цепочки тасков у нас и так есть,  
> > > 
> > > Нету.
> > > У нас есть только очередь абсолютно никак не связанных между собой
> > > сборочных заданий. https://bugzilla.altlinux.org/51923  
> >   Связанных, есть deps.  
> Нет. Пакет из одного задания не может быть собран с devel-пакетом из другого. 
> Это можно сделать только в одном задании.

  Вот и нужно сделать, чтобы мог! Кажется, это единственное, что нужно
сделать.

> >   Я им часто пользуюсь.  
> Я им постоянно пользуюсь.
> task ls --user=zerg --state=POSTPONED
> 
> >   Это значит, что одно задание может ссылаться на другое и это уже есть в   
> сборочнице.
> Это просто очередь, лишь порядок определённ мантенйером.

  Пока да. Разница в том, что в баге ты говоришь об общем репозитории
для очереди (группы), а я предлагаю подключать готовые репозитории
заданий в порядке следования очереди.

[devel] Re: Промежуточные сабтаски в сборочных заданиях

[Sergey V Turchin]

On Saturday, 2 November 2024 16:29:21 GMT+3 Paul Wolneykien wrote:

[...]
> > >   Это значит, что одно задание может ссылаться на другое и это уже есть
> > >   в
> > 
> > сборочнице.
> > Это просто очередь, лишь порядок определённ мантенйером.
> 
>   Пока да. Разница в том, что в баге ты говоришь об общем репозитории
> для очереди (группы), а я предлагаю подключать готовые репозитории
> заданий в порядке следования очереди.
Да, почти согласился, но только что подумал, что мой вариант лучше. У нас 
"нельзя смешивать репозитории", из-за чего будут возникать коллизии. Например, 
недавно я отправлял задание в p11, с которым не пересобирались 5 пакетов, но 
они тут же стали пересобираться, как только задание прошло в репозиторий. Это 
было только потому, что в момент проверки был подключен 2-й репозиторий со 
старыми пакетами. Правда, у всех пяти(не мои) BuildRequires были некорректные.

-- 
Regards, Sergey.

[devel] Re: Промежуточные сабтаски в сборочных заданиях

[Sergey V Turchin]

On Friday, 1 November 2024 21:31:59 GMT+3 Ivan Melnikov wrote:

[...]
> Может, возможно подойти к вопросу с другой стороны: не запихивать
> все промежуточные этапы в одну задачу, а выстраивать цепочки
> зависимых задач, способных использовать результаты сборки
> друг друга, и закоммититься только всей пачкой (т.е. либо
> все задачи из такой цепочки, либо ниодной)?
С языка снял. ;-) https://bugzilla.altlinux.org/51923

[...]

-- 
Regards, Sergey.