39 lines
6.2 KiB
Plaintext
39 lines
6.2 KiB
Plaintext
# source: 2026-10-18/rec_20261018_171535.m4a
|
||
# model: Systran/faster-whisper-small
|
||
# transcribed: 2026-10-20T20:01:36Z
|
||
|
||
[00:00:00] Понятно дело, где-то сбоку должна лежать таск habdb, то есть мы можем взять существующую службу
|
||
[00:00:11] задачей, вообще не перепиливая, на ней реализовать то, что нам нужно просто за счет DEV нового
|
||
[00:00:19] обработчика. Поэтому нужно проанализировать ее, выкачать исходники и реализовать рабочий процесс,
|
||
[00:00:27] пока ее не ломая. А вот дальше начинается самое интересное, когда у тебя DEV Taskhandler дошел до
|
||
[00:00:33] того, что ему надо, чтобы выполнить задачу, проклонировать к себе репозитории, мы приходим к
|
||
[00:00:40] вопросу, а куда он будет клонировать? И у нас есть два варианта. Если его клонируют прямо
|
||
[00:00:47] к себе, либо, наверное, что более логично, в примонтированную папку он клонирует репозиторию куда-то
|
||
[00:00:53] в общее пространство. А вот почему? Потому что когда DEV Taskhandler будет поднимать дополнительный
|
||
[00:01:04] контейнер с LOLM-кой, то он сможет тогда туда примонтировать тот репозиторий, который он проклонировал.
|
||
[00:01:22] Поэтому выгодно держать эту инфу вне контейнеров. То есть Task Hub должен создать временную папку и при
|
||
[00:01:32] подъеме контейнеров для DEV Taskhandler, то есть мы чтобы новый отдельный контейнер поднимать на
|
||
[00:01:44] каждый этот самый, значит, ранор должен это сделать. Что сделать? Создать временную папку. Но вопрос
|
||
[00:01:54] возникает, а DEV Taskhandler может работать в ней этой папке? Ну, он, наверное, может за счет нашей
|
||
[00:02:02] логики заранее определенной. Мы будем уверены, что он не запишется куда-то наружу. Либо, а вот
|
||
[00:02:10] контейнер будет с LOLM-кой и он соответственно у нас будет ограничен то, что ему будет папка
|
||
[00:02:16] примонтирована только с репозиторием. Ну, короче, Женя, я думаю, что нужно вот эту тему прогнать. Я имею в
|
||
[00:02:28] виду, что развернуть службу задач и вот просто собрать рабочий пайплайн, то есть вот Task Hub
|
||
[00:02:35] получает задачу. Он ее дает хендеру. Хендер, соответственно, готовит окружение и поджигает
|
||
[00:02:45] LOLM-ку. Понимаешь, да? То есть поджигает еще один контейнер, которому удается эта репозитория и
|
||
[00:02:56] пром соответствующий. То есть вот, наверное, как сейчас это самое. То есть в итоге получается,
|
||
[00:03:01] что если мы в Task Hub запушим последовательность задач, у нас там есть вроде зависимости между
|
||
[00:03:09] задачами, то есть когда одна задача выполняется, вторая соответственно начинается, то служба
|
||
[00:03:20] задач должна мочь за счет подъема дополнительной, ну, короче, за счет работы DevTaskHander и который
|
||
[00:03:29] управляет подъемом контейнеров с LOLM-кой, выполните эти задачи. Здесь тонкий момент, ну, вот это понятно?
|
||
[00:03:38] Да. Тут тонкий момент только в том время жизни репозитория. То есть по-хорошему время жизни
|
||
[00:03:46] репозитория не должно быть связано с временем, ну, с циклом жизни обработки задач. То есть мы репозиторий
|
||
[00:03:58] колонируем, когда надо задачей работать, и мы репозиторий как бы убираем, когда мы заканчиваем.
|
||
[00:04:10] По-хорошему, наверное, можно сделать какой-то тип задачи с определенным DevTaskHander,
|
||
[00:04:16] то есть, который вообще без LOLM-ки, и получится, смотри, какая петрушка. И кстати, это интересная
|
||
[00:04:22] штука. То есть у нас с тобой ставится одна или даже несколько задач, и сразу она закидывается в
|
||
[00:04:30] DevTaskHander цепочкой. И первая задача идет, грубо говоря, колонированная репозитория, а последняя
|
||
[00:04:37] задача идет за его зачиска. А в середине идут куски разработка, верификация, согласование, они могут
|
||
[00:04:44] вот так вот бурбулировать, туда могут новые задачи накидываться. Ну, понимаешь, да? А заканчивается
|
||
[00:04:50] это все тем, что в итоге, когда все задачи выполнены, от которых зависит зачиска репозитория,
|