d-stream

Если запускать тесты без асинхронщины - то тупо
команда запуска теста 1
команда запуска теста 2
...

Рекомендую заглянуть в config.toml раннера и почитать доки.
Всего этого при наличии ресурсов достаточно чтобы сделать и 2 и 10 и даже разных раннеров на одной машине.

А точно это ssh гита, а не ssh машины?
По-умолчанию на 22 порту слушает ssh хостмашины, а ssh гита - живёт вроде бы на 2222 порту

Естественно лучше это поменять:
https://docs.gitlab.com/ee/administration/operatio...
https://about.gitlab.com/blog/2016/02/18/gitlab-do...

Как угодно. Он просто выполняет инструкции прописанные в .gitlab-ci.yml а инструкции могут включать и например цикл по списку хоть 100500 серверов

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

Бинарникам - не место в нём.

Можно конечно наплодить нотификаторов для каждого задания... Но как мне кажется проще "врезать" нотификацию в сами задания шага test

ps. Успех/неуспех проще всего ловить взводя флаг в before_script/script и обрабатывать в after_script

это явно не уникальная задача и поэтому первый же результат поиска "migrate svn to gitlab" приводит на сайт гитлаба

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

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

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

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

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

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

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

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

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

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

Ну хранить бинарные это в гитлабе - по мне не самая лучшая идея. Идеологически пакеты - это результаты а не исходный материал. Как один из вариантов - использовать внешнее хранилище. К примеру 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:)