смотря какой порог поставить :)

смотря какой порог поставить :)

0

отличный порог

билд как таковой - указатели на состояние нескольких реп

noc

custom

collections

отличный порог

шикарный

состояние -- URL repo, changeset, branch

кладем это, условно, в json

и как-то обзываем

у билда есть артефакты

скажем, docker image hash

rpm'ки и deb'ы

etc

в зависимости от окружения устанавливается транспорт

где-то тащит по hg

где-то -- бинарями

или питоновскими колесами

ну и теги у билдов

@freeseacher ты просто не смотришь с другой стороны, ты думаешь кто-то добровольно будет что-то качать и тестировать, но это не совсем доровольно, у человека есть выбор, либо создать класс/модель самому либо выкачать готовую и использовать/поправить косяки и потом использовать. Тут у человека будет мотивация собственной ленью использовать тестовые коллекции - благо они почти ничего не могут сломать. А голосовать/не голосовать - это лишь зависит от того как сложно вы организуете этот процесс, чем проще тем лучше

коллекции, кстати, могу сделать с оверлеями

будет пирог

теперь как я это вижу :) * берем ночную ревизию, делаем из нее deb, rpm, tar.gz, docker. пишем зависимости. * выкладываем в репы. * при генерации tag в меркуриале - делаем версию * именование версий ночных идет по принципу {tag}-{revision}-{date} ну и latest

из нескольких источников и приоритета между ними

какие-то билды будем передавать в Q&A

Немного 5 копеек насчёт моделек. Я могу взяться за модельки. Единственное, надо подумать насчёт того - как мне их тестировать. Одна из причин почему там мало делают моделек, всё-таки, в трудозатратах. Вот н-р мои модельки уже года как висят не добавленные?

если бы удалось как-то стандартизировать пути добавления и упростить процедуру

удваиваю

добавления, думаю, у людей появилось бы больше возможности поучаствовать

вообще это проблема по добавлению моделей и другого "контента"

ну для начала коллекции нужно оверлеями сделать

типа дистрибутивная, тестовая и локальная

если файлик есть - он перекрывает все менее приоритетные

манифесты совсем выпиливаем

ну для начала коллекции нужно оверлеями сделать

мы считаем это свершившимся фактом и смотрим в будущее

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

и еще - я достаю mib'ы из share/mibs

укладываю их в отдельный пакет

распаковывать будем в var/mibs

кстати

вот по поводу мибов

они же гдето должны лежать

что бы их паковать

так что по всей видимости они уезжают в репу отедльную

и что то мне думается что так же будет происходить с отсальными пакетами

так что может быть сделать репу в которой бы лежали сорсы для сборки пакетов npkg ?

@dvolodin

не стоит

она огромная будет

да и пофиг

ты же туда притащишь изменения всех зависимых пакетов

к ней только ci будет лезть

нафига оно

накрайняк - указывать, откуда тянуть версию

ну вот будет внешняя репа на битбакете. в ней с той структурой про которую мы говорили леат файлы.

ci тащит репу при обновлении и собирает из нее пакеты

скалыдывая в нужное место.

если без src, то можно

тогда для выкладки нового codemirror адо будет просто в эту внешнюю репу кинуть новый файл

по логике вещей накачанные дистрибутивы должны оставаться на ci

или жопа будет

во нафлудили-то ;)

те же sencha любят тереть старые версии с cdn

ну вот а у нас будет отдельно сложено

по логике вещей -- коммит в npkg -- указание собрать новый пакет

и положить его на cdn

да

чтобы он начал использоваться в noc -- второй коммит уже в сам noc, с указанием версии

а нало ли ?

да, конечно

смотри

может надо еще делать линковку на latest ?

тестирую я ext 6.1

неее

мы используем только версионированые версии чужих пакетов

ладно пофиг.

пусть так

latest - будет считаться то, что собралось и прошло тесты

сейчас есть в бт 100500 таких вот реп https://bitbucket.org/nocproject/noc-pkg-extjs/src

они не нужны?

не нужны

их npkg заменил

вот эту точно можно херить https://bitbucket.org/nocproject/noc-contrib-src/src

это да

удаляю ее

да оставь пока

мало ли у кого совсем древние версии

где contrib как subrepo

ладно хорошо.

тогда делаю одну репу отдельную

называю npkg

запиливаю к ней ci на базе bitbucket pipeline

решил все-такие ее?

ну она есть

по воводу gitlab ты плачешь что не hg

новую репу и в git можно

ну так всё.

забилилсь :)