d-stream

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

Ну и вроде на 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 контент (не меняя линки)

Ну хранить бинарные это в гитлабе - по мне не самая лучшая идея. Идеологически пакеты - это результаты а не исходный материал. Как один из вариантов - использовать внешнее хранилище. К примеру sonatype nexus. Притом он умеет и не только в .nuget. Бонусом - его умение полноценно поддерживать nuget-api. То есть не возникнет вопросов при использовании пакетов и восстановлении транзитивных зависимостей.
Конечно в .nuspec можно и нужно заполнять честно Видимо да, корнем будет Company или нечто подобное для группы компаний.
Дальше видимо отдельная ветвь нечто совсем общего для всех продуктов со своим ветвлением на lib/utils/helpers/etc и ветвления на продукты, где далее опять же нечто общее для всех версий и далее ветвление по версиям и дальше уже опять же modules/libs/utils

(кстати внутреннюю делёжку можно подсмотреть со стороны самой структуры дерева в nuget (рекомендуемая структура target от ms)

То бишь в итоге получится нечто типа такого:

Brand
 - CommonBrandSubTree
   - *
 - Subbrands
   - SubbrandsCommon
     - * 
     - ProductX 
       - ProductCommon
       - *
     - ProductY 
       - ProductCommon
       - *
________
* - это то самое lib/tools/frameworks/etc

Притом не стоит бояться слишком разветвлённого дерева - хотя на первом этапе это и будет выглядеть чрезмерно переинженеренным. Зато потом не придётся его ломать и ветвить на ходу.

Ну а смысл в общем-то есть: у среднего человека мгновенная память/восприятие способна охватить "за раз" 5-9 объектов и исходя из этого максимально комфортной структурой окажется дерево, где на каждом уровне будет видно где-то по 5-9 объектов.

Естественно волшебных гениев не существует и самую идеальную структуру не создать. Но можно посмотреть на те же имена от ms - где более-менее просматривается что-то подобное, но с итерациями к подходу (ветвление по платформам, архитектурам начали появляться попозже и т.п.)

с длиной имён путей/файлов - да можно огрести чуть дальше - на уровне сборки - win-раннеры не умеют в \\?\driveletter и воспользоваться вариантом длины пути в 32767 символов не выйдет...

p.s. ну и по-любому морально стоит готовиться к какому-то кардинальному моменту, когда захочется начать новое дерево с нуля - этакую v.2.0 (возможно стартовав такое уже в другой компании))

ну примерно вот так:

image: # имя докер-образа 

stages:
  - build
  - tests
  - deploy

build_my_project:
  stage: build
  tags: 
    - тэг раннера где запустить
  script:
    - ... # собственно действия для билда
    - ... 
    - ...
    - ...
  artifacts:
    name: как будет обзываться артефакт сборки
    paths:
    - путь до файлов в артефакт
    expire_in: 1 hour # сколько ему жить
test1: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  needs:
    - build
  scripts:
    - # действия по выполнению теста

test2: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  scripts:
    - # действия по выполнению теста 2

deploy_to_dev:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "development"
  scripts:
    - # действия деплою в dev


deploy_to_prod:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "master"
  scripts:
    - # действия деплою в dev

словами: на первом шаге - build выполнится то что прописано в scripts (последовательно, по строкам)
на втором шаге - test - параллельно выполнится два (ну или сколько надо блоков тестов)
на третьем - deploy - выполнится или deploy_to_prod или deploy_to_dev или ничего в зависимости от того в какой ветке идет сборка ($CI_COMMIT_BRANCH)
image: # имя докер-образа - имя соответсвующего docker-образа с подготовленной средой разработки (node:14 - для npm, mcr.microsoft.com/dotnet/sdk:6.0 - для .net6 и так далее)
можно и любой свой

needs: - описывает от каких шагов зависит шаг (это относительно свежее, ранее более жесткое dependencies:)

Первое как уже подметили - это mode http
Второе - все обращения к test.test2.ru/bla-bla будут соответствовать условию hdr_beg(host) -i test.test2.ru
Ибо это звучит как "хост в заголовке начинается с ..."
Соответственно как минимум стоит оперировать с вариациями path*

например совсем грубо:

redirect code 301 localtion  test.test2.ru/user/login  if { path / } # тогда и только тогда когда путь в uri будет /

или чуть поизвращённей (если вдруг в path test.test2.ru не окажется ведущего /):

redirect code 301 localtion  test.test2.ru/user/login  if {  path_len 0-1  } # *

_________________
* - судя по мануалу "Returns true when the path length matches the values or ranges specified." но как именно задать range "0-1" или "0 1" или "0,1" подсказать затрудняюсь

По сути - достаточно просто исключить термин "плагин" и всё становится на свои места.
Просто применяем термин "нечто". После этого готовим механизм вызова этого нечто и api с которым это нечто должно уметь взаимодействовать. Профит. Это нечто может быть написано даже на языках программирования, которые придумают в 2025 году)
Естественно чтобы всё это взлетело - не помешает так же выступить автором заготовок/фреймоков для большинства яп.

Законно.
Никто не запрещает даже спать на потолке и какать стоя. Но это неудобно и ноги постоянно пахнут.

Поэтому в рамках развития и поддержки программы - доводить её до более удобного в плане поддержки и развития состояния. Естественно изучив материалы про рефакторинг и его концепции (Кериевски, Мартин и др).

В данном случае все прыжки от cat5e - сродни аудоиофильским подставкам под электрические кабеля, отполированными девственницами в полнолуние. И прочей веселухе оного рода.
Нерационально, но если продают - то значит маньяков хватает. И если по весне вдруг возникает непреодолимое желание - то наверное да, стоит продать квартиру и прикупить что-нибудь этакое)

Собственно про плюсы и минусы засыпания уже расписали.
А вот про реализацию непросыпания при сканировании - давно уже есть такое понятие как port knocking
то есть в меру своей паранойки можно задать последовательность номеров портов и только при обращении в этой последовательности - будить.

Образчик для микротика

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

Классика: две кнопки "пуск" и "стоп" + прогрессбар
IsEnabled у кнопок цепляется за булево поле IsProcess (инверсно у пуск и прямо у стоп)
ProgressBar - виден только когда IsProcess == true

Пляжный ноут 2010 года сходной конфигурации вполне прилично тянет 2022 под win11.
Притом не проекты для изучения, а боевые.

Само собой что на i9 10 поколения и 32Гб озу всё это заметно комфортнее)