Поясните, как собирать с gitlab-ci?

gitlab runner поставить, по идее

gitlab runner поставить, по идее

Я поставил, прочитал хелп - так и не понял

Единственное, чего я не смог внятно понять - в проектах есть .gitlab-ci.yml с полным рецептом по сборке. Мне обязательно открывать его вручную каждый раз, копировать тупо по строчке и выполнять, или всё же есть способ выполнить его автоматически на локальной машине, если я просто утянул проект с гита и хочу собрать, и не собираюсь заводить никакие аккаунты и куда-то что-то лить?

Оно и видно, что ты не понял.

.gitlab-ci.yml - не рецепт по сборке, а рецепт по тестированию и прочей интеграции. Если он при этом еще и что-то там собирает, это дело вторичное. Чтобы собирать, дергай систему сборки проекта той командой, которая это делает. Если таких простыня - запили скрипт с не-простыней и дергай его.

Показалось странным, там есть например раздел build и там полная инструкция довольно обширная, а если для деб - даже какие репы подключить может быть и где ключик утянуть.
Ну т.е., надо открывать каждый раз вручную, копировать нужное содержимое в шелл скрипт и запускать его... За сегодняшний день в разных местах несколько раз с таким столкнулся, да уж.
Так а зачем это вообще? Там про какие-то папйпы было, проверку статуса задания. Система удалённой сборки что ли?

Да. Типа «возьми докер-ин-докер, собери образ, залей образ, скачай образ, _собери программу_, залей программу в артефакты, скачай программу из артефактов и другой образ, попробуй установить, прогони тесты, залей куда-то еще, высвети зеленый значок.

„Собери программу“ тут - шаг мелкий и, возможно, как-то особо для CI производящийся, раз у тебя там не одна команда.

Иди читай, короче.

Так а зачем это вообще? Там про какие-то папйпы было, проверку статуса задания. Система удалённой сборки что ли?

Так можно сказать только если с натяжкой. Про Continuous Integration (CI) не слышал, что ли? Смысл в том, чтобы упростить цикл сборки/тестирования/деплоя при разработке. В самом простом виде это представляет собой сценарий, который выполняется для каждого коммита, который запушен в удалённый gitlab-репозиторий.

Тем не менее, многие CI-системы (в том числе и Gitlab CI) позволяют сохранять артефакты сборки после успешного прогона сценария (но это нужно уже смотреть в конкретных проектах). Но стоит понять, что редко когда CI используется только ради получения артефактов сборки — чаще акцент идёт на тестирование и деплой.

Вот тебе пара сценариев для примера:

1. Вы в компании разрабатываете сайт, вас в компании N человек. Для сайта у вас разработана система тестов, есть автоматические проверки кода на соответствие стилю с помощью различных линтеров и т.д.

   Так вот, когда твой коллега сделал какую-то фичу, то ты, перед тем как принять эту фичу, хочешь быть уверен, что сайт успешно собирается, проходит все тесты и пр. Ты не приходится самому собирать его ветку вручную, чтобы это проверить (так как чувак это может забыть, а ты не можешь стоять над ним с кнутом), т.к. CI автоматически прогонит сценарий и даст тебе ответ, выполнился ли он успешно или нет (это будет видно как для индивидуального коммита, так и для Pull/Merge Request'а).

   Кроме того, когда ты сольёшь эту ветку в dev, то CI автоматически выкладывает сайт на staging-сервер для того, чтобы другие разработчики/тестеры могли руками потрогать новые изменения. После того, как ты убедился, что всё ок, то ты сливаешь это всё ветку master, и изменения выкатываются автоматически уже на продакшн сервер.

2. Ты разрабатываешь open source тулзу. Ты (или даже какой-то левый васян, которого ты никак не заставишь прогнать тесты) добавляешь новую фичу/фиксишь баг. CI собирает тулзу, прогоняет тесты, ты убеждаешься с некоторой долей уверенности, что новая фича ничего не ломает. Когда эти изменения достигают ветки master, CI может автоматичски собрать пакеты/бинарники и сохранить их как артефакты системы сборки и/или залить их на удалённый сервер.

Эта штука для разработчиков, а не для пользователей продукта. Ключевой момент тут — автоматизация всего процесса.

Касаемо использования Gitlab CI в качестве локальной системы сборки — это возможно в теории (сам я не пробовал), см. gitlab-runner exec, но у этого способа есть туча ограничений, например, он не поддерживает артефакты сборки. Но я думаю, что в крайнем случае их можно будет вытащить из контейнера, если получится успешно запустить сценарий сборки.

в проектах есть .gitlab-ci.yml с полным рецептом по сборке

Это не рецепт по сборке, это ci.