ru_gitlab

26 Jul 2025 08:45

с protected тоже есть траблы, когда идет mr в mainline (protected) или в tag (protected) то переменные protected не могут быть использованы
это в gitlab и зачем тогда мне переменные протектед?
удалил их...
типо для безопасности так сделали чтобы разраб не сделал echo $PROTECTED_VARIBALE

ru_gitlab

26 Jul 2025 07:45

Проблема была во флаге protected при сохранении переменной. Никто и не подсказал об этом

ru_gitlab

25 Jul 2025 22:48

кроме оф доки по линку выше ничего дать не смогу

ru_gitlab

25 Jul 2025 22:42

я сталкивался с генерацией как юзер на уже готовом пайплайне, но работало это откровенно странно

ru_gitlab

25 Jul 2025 22:38

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

ru_gitlab

25 Jul 2025 22:34

вообще не вариант.
"Отдельно референсни переменные, отдельно пре, потом скрипт, потом пост, а всякие тэги видимо лесом. Или тоже отдельно референси"
Ну или выносить условно "файл где всё для сборки", оно хоть как-то работать будет. Это при том, что extends работает ровно так, как нужно.

ru_gitlab

25 Jul 2025 22:27

Нормальный для реюза кода, куда деваться)

ru_gitlab

25 Jul 2025 22:25

а в случае анкоров там вообще нет блока

cat set_tag.yml
.set_tag: &set_tag
  - |
      if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        tag="latest"
        echo "Running on default branch '$CI_DEFAULT_BRANCH': tag = 'latest'"
      else
        tag="$CI_COMMIT_REF_SLUG"
        echo "Running on branch '$CI_COMMIT_BRANCH': tag = $tag"
      fi

ru_gitlab

25 Jul 2025 22:19

какой чудовищный костыль этот !reference..

ru_gitlab

25 Jul 2025 15:48

в docker-deploy.yml: нет такого якоря

ru_gitlab

25 Jul 2025 14:31

Ладно, всем спасибо за помощь. Всем пока

ru_gitlab

23 Jul 2025 19:00

Тогда вопрос ближе к теме этого чата: если кто-то имел опыт настройки GitLab CI для сборки программ под Windows, какой executor Вы выбрали, как настроили, как оптимизировали?

ru_gitlab

23 Jul 2025 18:34

Это не проблема Gitlab Runner – запустив сборку в контейнере вручную, получаю те же результаты :(

ru_gitlab

23 Jul 2025 16:10

Привет!
Не получается с GitLab Advanced SAST разобратся.
У меня self-hosted GitLab EE 17.4 Ultimate Lic.
Включил Advanced SAST для одного из проектов полностью на TypeScript написанном. Хочу чтобы анализатор GitLab Advanced SAST делал проверки специфичные только для TypeScript - все перепробовал но Advanced SAST продолжает писать в лог про правила для прочих языков.

Содержимое .gitlab-ci.yml репы проекта на TypeScript:

include:
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
- template: Jobs/SAST.gitlab-ci.yml
- template: Jobs/Secret-Detection.gitlab-ci.yml
- project: 'global/templates'
ref: main
file:
- 'NodeJs/Node.js.gitlab-ci.yml'

variables:
GITLAB_ADVANCED_SAST_ENABLED: 'true'
DS_MAX_DEPTH: -1
SEARCH_MAX_DEPTH: 20
NODEJS_IMAGE: node:19-alpine

ru_gitlab

23 Jul 2025 15:12

А ну вот. И проблема. Странно, конечно

ru_gitlab

26 Jul 2025 08:13

у меня сборки легли именно из-за эскейпинга, я засунул публичный серт 300КБ в переменную и все сдохло, а на ui все окей было

ru_gitlab

26 Jul 2025 07:20

да, тоже убил одной переменной сборку всех команд, баг какой-то ну и у гитлаб свой эскерйпинг например $$ для $ в gitlab, а в bash \$ - $...

$ sha256sum /usr/local/bin/yq
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  yq

$ YQ=$(cat /usr/local/bin/yq)
$ echo "$YQ" > yq_var_bin

$ echo -n "$YQ" > yq_var_bin
$ sha256sum yq_var_bin
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  yq_var_bin

ru_gitlab

25 Jul 2025 22:45

в основном go-template, вроде https://github.com/hairyhenderson/gomplate
синтаксис похож на helm, его все умеют
но на огромных пайпах это больно

ru_gitlab

25 Jul 2025 22:42

а вы генерите? Как, чем?

ru_gitlab

25 Jul 2025 22:34

ощущение что реально делать нормально рядом, а потом генерить мега-файл

ru_gitlab

25 Jul 2025 22:29

а что можно лучше натянуть в ямле? в самых запущенных случаях все вообще скатывается в автогенерацию пайпов из шаблонов. и в гитхабе не лучше дела

ru_gitlab

25 Jul 2025 22:26

можно конечно говнокодить, напрямую копируя блоки, но *ля, кто ж так делает

ru_gitlab

25 Jul 2025 22:21

The extends keyword, which is more flexible and readable. You should use extends where possible.
в той же доке

ru_gitlab

25 Jul 2025 15:50

https://docs.gitlab.com/ci/yaml/yaml_optimization/#reference-tags тебе нужно это

ru_gitlab

25 Jul 2025 15:44

ошибка
Unable to create pipeline
https://gitlab.com/ччч/gitlab-components/raw/master/pipeline/docker-deploy.yml: An alias referenced an unknown anchor: set_tag

.gitlab-ci.yml

include:
  - https://gitlab.com/ччч/gitlab-components/raw/master/pipeline/set-tag.yml
  - https://gitlab.com/ччч/gitlab-components/raw/master/pipeline/docker-deploy.yml

include:
  - https://gitlab.com/ччч/gitlab-components/raw/master/pipeline/set-tag.yml
...
.deploy:
...
  before_script:
    - *set_tag

ru_gitlab

25 Jul 2025 14:31

ты ее вывел, она пустая

ru_gitlab

23 Jul 2025 18:58

С этим в другой чат, без вариантов.

ru_gitlab

23 Jul 2025 18:29

Добрый вечер. Может, кто сумел побороть проблему:

docker-windows executor для Gitlab runner-а ОЧЕНЬ медленный, по сравнению с shell executor. Разница почти 5 раз. При этом в настройках Docker стоит isolation=process (hyperv еще медленнее), ограничений на ресурсы не установлено. Проект MSVC-only, то есть нужно собирать для Windows из-под Windows.

Примерные тайминги для docker-windows:
конфигурация cmake - 3 минуты
сборка - 17 минут.

Тот же проект в shell executor суммарно собирается примерно за 4-5 минут.

Есть ли возможность ускорить docker-windows или сделать shell executor более безопасным и "удобным" (автоматическая очистка окружения после сборки и т.п.)

ru_gitlab

23 Jul 2025 15:18

Грешу на сам orangepi, остальное перепробовал

ru_gitlab

23 Jul 2025 14:57

добавил graceful_kill_timeout = 5 и force_kill_timeout = 5
ребутнул ранер и ничего не поменялось, компилятор продолжает работать в 8 потоков

полез на раннер смотреть sudo journalctl -u gitlab-runner -f как оно вообще там живет, задание приходит, начинается работа, затем я прерываю джобу и вижу

WARNING: Appending trace to coordinator... job failed  code=403 correlation_id=01K0VNDBW
WARNING: Failed to terminate process: no such process  PID=199094 job=90218
WARNING: Failed to force-kill: no such process      PID=199094 job=90218