d-stream

Вообще раннеры - это из категории сборки, а деплой - подразумевает отправку результатов сборки на продуктовые/тестовые контура

То есть гитлаб командует раннеру/раннерам дабы они осуществили сборки, а потом отправили результаты успешной сборки на те сервера где вертится продукт

Самое простое - в commit message поместить "волшебный" текст [skip ci] либо передать опцию ci.skip гиту
Либо менять слегка схему сборки и там уже либо реагировать на условия, а в остальных случаях например не собирать (gitlab yml when/rules)

Думаю для начала стоит поглядеть в msconfig - не установлен ли лимит памяти (msconfig - загрузка - доппараметры загрузки)

Долго ковырял подобное, в итоге пришел примерно к такой реализации:
- таблица pk для обновления
- прикладная часть запрашивает диапазоны из этой таблицы и дёргает процедуру обновления с указанием диапазона
- старт идёт с короткого диапазона, если время выполнения не превышает психологический порог - на следующей итерации - берётся порция большего размера и так до порога времени выполнения

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

1. XML_Schema (собственно то что называют xsd
2. вот п.1 и хранить (либо см. п.3)
3. для большинства яп существуют библиотеки/фреймворки которые как раз умеют:
- создать описания классов по схеме (xsd)
- сериализовывать/десериализовывать экземпляры

xslt - чуть из другой оперы - это язык описания преобразования одной схемы в другую

Категории кабеля не имеют понятности актуальности. Каждая из них имеет свой диапазон применимости. В диапазонах до 1Гбит/с - категория 5e - сверхдостаточна и оптимальна. Аналогия: фапать на кабель AWG-0000 для зарядки сотового телефона)

Домашние провайдеры не предоставляют услуг гарантированного канала - поэтому и тарифы "10Мбит" и "1гигабит" и "100500гигабит" звучат так только в рекламном булшите... в договорах звучит как "..скоростью [от нуля] до xx Гбит/с [до порта провайдера]" и в переводе на человекопонятный язык это выглядит как:
- даже скорость 0 (ноль) гигабит/с в таких тарифах юридически допустима и нормальна
- это скорость от квартиры до ближайшего коммутатора, не более...

Так что в принципе всё это скорее развод для лошков)

Классика жанра:
абоненты домового провайдера подключены гигабитом до ближайшего коммутатора, который... подключен оптикой к оптическому коммутатору ядра... тоже гигабитом... А ядро имеет пару-тройку 10 гигабитных аплинков до IX

Дальше можно прикинуть что будет когда 48 жителей одного подъезда вдруг зарядят например закачку торрентов))

Ну и да: более-менее нормальные сайты и ресурсы обязательно шейпят отдаваемый в одни руки поток... как правило не очень быстрый

Можно.
Обычно так и делают. Например в зависимости от переменной CI_COMMIT_BRANCH (ветка)

OEM лицензия windows подразумевает что производитель поставляет оборудование с windows [11] как единое целое. Естественно подразумевается что это самое изделие в виде железа и софта - работоспособно.
Соответственно остальная часть вопроса в такой постановке не имеет смысла.

Один из вариантов - использование скриптом конфигурационных (env) файлов, которые не деплоятся в рамках сборки, а живут на каждом конкретном сервере (разовая первоначальная настройка).

А чего бы не попробовать?
То есть тупо нарисовать простейший .gitlab-ci.yml из одного стейджа:

image: alpine:latest 
stages:
  - Build
Build:
  stage: Build
  script:
    - echo Worked!

и потом полюбоваться на лог

По крайней мере по ссылке пишут про своего рода "продуктовые" (стартапы, opensource) linux раннеры на гугловых машинках со свежим докером

Ну самое простое - выдать сколько-нибудь и потом смотреть в мониторинге фактическую загрузку [ну и слушать жалобы пользователей]. По результатам мониторинга - корректировать выделение ресурсов.

Надо превратить эту библиотеку во множество nuget пакетов [вместо одного самолёта с зонтиком, гусеницами, бассейном и теннисными кортами]

nullable bool полностью покроет варианты
ну и всякие ifnull для полного счастья

Надо вспомнить что "рядом" с ad - LDAP

https://www.python-ldap.org/en/python-ldap-3.4.0/r...

Первые же результаты поиска "продажа домена юрлицами" приводит:
- в консультат+ где готовая подборка документов для этого плюс статьи комментарии
- на кучку регистраторв, которые оказывают услуги гаранта (естественно за %%)

Ну и вроде на nic.ru был магазин, где он вообще выступал "промежуточным звеном" - т.е. юрлицо продаёт/передаёт nic, а тот уже продаёт от своего имени другому юрлицу

Не совсем понял про есть или нет линия сборки...
Если всё-таки есть - то использовать например CI_PIPELINE_ID или CI_PIPELINE_IID из предопределенных переменных.

Теоретически можно смаппить "букву диска" сетевому пути
то бишь net use x: \\share\folder
Но это в любом случае не лучшая идея (мягко говоря).
Сам сервис mysql рассчитывает на более быструю и надёжную работу со своим файлом data чем обеспечивает бытовая связка nas-хост

"купленный домен" - это скорее купленная запись в общепринятом справочнике.
то бишь все, сунувшиеся на domen.org получат справку что надо идти по ip адресу 1.2.3.4
И они пойдут
А дальше сервер на этом адресе - должен слушать обращения и отвечать.

Отсюда:
надо на сервере начать слушать обращения - то бишь 80 порт для http и 443 порт для https и переправлять это тем или иным образом приложению (которое слушает в данном случае иной порт)

Наиболее распространенные варианты - это например nginx, haproxy и т.п.

Теперь про "имя сервера": собственно никто не мешает для кучи разных доменных имён указать один и тот же ip адрес и все обращения будут прилетать к одному серверу (L3), но в каждом обращении будет фигурировать имя к которому обращались (L7) и то самое, что слушает 80/443 порт по этой информации может например передавать (проксировать) обращения например в разные приложения/контейнеры/порты

Итого: поднять на самом сервере или в контейнере nginx/haproxy и прописать в конфигах:
при обращении domen1.org - перенаправлять в контейнер на порт 8000, когда-нибудь потом добавить что при обращении к domen2.org - перенаправлять на соседний контейнер на порт например 8001

Ну или пока упростив - слушать контейнером 80/443 порт ( 80:8000 ) и внутри контейнера пока ничего не делать дополнительного пока не появится второй домен

Видимо такое может быть. Почему иногда реализуют всякое разное типа:
- 301 в заголовках
- в html "туда идите" с линком + js-редирект в теле

Как вариант такого эффекта "неперехода" можно добиться накрутив всякие параноидальные настройки броузера.

p.s. с чем можно было бы "поиграться":
- выпустить серт в виде "один на всё" где в SubjectAltName будут все 4 или более вариации имён
- добавить еще и js-редирект
- попробовать отдавать по www.xx.yy полностью идентичный yy.xx контент (не меняя линки)