Показаны сообщения с ярлыком gitlab. Показать все сообщения
Показаны сообщения с ярлыком gitlab. Показать все сообщения

30 июля 2026

Обновление зависимостей в GitLab

Делал исследование на тему автоматизации обновления зависимостей в GitLab по аналогии с GitHub Dependabot.

Чаще всего приходится обновлять:

  • GitLab CI скрипты
  • Версии Helm чартов
  • Теги контейнерных образов, которые использует Helm чарт

Поиск в сети дал три кандидата, которые более-менее подходили под эти требования:

Dependabot-gitlab 

Про dependabot-gitlab особо рассказать нечего. Он является обёрткой над dependabot-core. Я не нашёл какой-либо информации о поддержке обновления CI скриптов GitLab поэтому этот вариант был сразу отброшен.

04 мая 2026

GitLab CI/CD job token

Решил сделать пометку на память, т.к. было потрачено изрядное количество времени на отладку пайплайна Terraform в GitLab.

Началось с рутинной установки нового компонента, которая прервалась на этапе выполнения инициализации Terraform:

│ Error: Error accessing remote module registry
│ 
│   on example.tf line 1:
│    1: module "example" {
│ 
│ Failed to retrieve available versions for module "example" (example.tf:1)
│ from gitlab.example.com: error looking up module versions: 403 Forbidden.

Выглядело как "протухший" токен, но локально с этими кредами новый модуль выкачивался. Дальше было несколько часов возни и в итоге коллега нашёл что дело в изменениях, связанных с GitLab CI/CD job token.

12 марта 2026

Обновление ключа подписи репозитария GitLab

При установке обновлений APT выдал ошибку об устаревании ключа, которым подписан репозитарий Gitlab:

Get:5 https://packages.gitlab.com/gitlab/gitlab-ce/debian trixie InRelease [16.9 kB]
Err:5 https://packages.gitlab.com/gitlab/gitlab-ce/debian trixie InRelease
  Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on F6403F6544A38863DAA0B6E03F01618A51312F3F is bad:            The primary key is not live   because: Expired on 2026-02-27T20:15:41Z
Fetched 239 kB in 1s (361 kB/s)
1 package can be upgraded. Run 'apt list --upgradable' to see it.
gitlab-ce is already the newest version (18.7.5-ce.0).
Selected version '18.7.5-ce.0' (gitlab-ce:1/trixie [amd64]) for 'gitlab-ce'
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: https://packages.gitlab.com/gitlab/gitlab-ce/debian trixie InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on F6403F6544A38863DAA0B6E03F01618A51312F3F is bad:            The primary key is not live   because: Expired on 2026-02-27T20:15:41Z
Warning: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/debian/dists/trixie/InRelease  Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on F6403F6544A38863DAA0B6E03F01618A51312F3F is bad:            The primary key is not live   because: Expired on 2026-02-27T20:15:41Z
Warning: Some index files failed to download. They have been ignored, or old ones used instead.

Чтобы обновить ключ достаточно следовать инструкции. У меня не установлен curl, поэтому немного изменил команду для дистрибутива Debian Trixie

$ sudo mkdir -p /etc/apt/keyrings

$ sudo wget -O /etc/apt/keyrings/gitlab-keyring.asc https://packages.gitlab.com/gpg.key

$ echo 'deb [signed-by=/etc/apt/keyrings/gitlab-keyring.asc] https://packages.gitlab.com/gitlab/gitlab-ce/debian/ trixie main' | sudo tee /etc/apt/sources.list.d/gitlab-ce.list

$ sudo apt-get update

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

11 ноября 2025

Сломалась сборка образов в Gitlab

 Сегодня сборка Docker образов сломалась на docker-machine ранерах.

*** WARNING: Service runner-xxxxxxxx-project-xxxxx-concurrent-0-xxxxxxxxxxxxxx-docker-0 probably didn't start properly.
Health check error:
service "runner-xxxxxxxx-project-xxxxx-concurrent-0-xxxxxxxxxxxxxx-docker-0-wait-for-service" health check: exit code 1
Health check container logs:
2025-11-11T14:15:01.392368160Z FATAL: No HOST or PORT found                      
Service container logs:
2025-11-11T14:15:01.155180886Z cat: can't open '/proc/net/ip6_tables_names': No such file or directory
2025-11-11T14:15:01.156146175Z cat: can't open '/proc/net/arp_tables_names': No such file or directory
2025-11-11T14:15:01.159149102Z iptables v1.8.11 (nf_tables)
2025-11-11T14:15:01.198255845Z time="2025-11-11T14:15:01.197837859Z" level=info msg="Starting up"
2025-11-11T14:15:01.201660747Z time="2025-11-11T14:15:01.201577762Z" level=warning msg="Binding to IP address without --tlsverify is insecure and gives root access on this machine to everyone who has access to your network." host="tcp://0.0.0.0:2375"
2025-11-11T14:15:01.201682858Z time="2025-11-11T14:15:01.201643206Z" level=warning msg="Binding to an IP address, even on localhost, can also give access to scripts run in a browser. Be safe out there!" host="tcp://0.0.0.0:2375"
2025-11-11T14:15:01.201770114Z time="2025-11-11T14:15:01.201692789Z" level=warning msg="[DEPRECATION NOTICE] In future versions this will be a hard failure preventing the daemon from starting! Learn more at: https://docs.docker.com/go/api-security/" host="tcp://0.0.0.0:2375"

Вызовы docker завершались ошибкой

ERROR: Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?

Связано это с выходом Docker 29.0.0, который перестал быть совместимым с docker-machine (подробности есть в gitlab-org/gitlab-runner #39100 и cattle-ops/terraform-aws-gitlab-runner #1324).

Для исправления достаточно откатиться на предыдущую версию Docker добавив engine-install-url=https://releases.rancher.com/install-docker/28.3.3.sh в MachineOptions

Если используется модуль cattle-ops/terraform-aws-gitlab-runner, то это делается через добавление параметра

  runner_worker_docker_machine_ec2_options = [
    "engine-install-url=https://releases.rancher.com/install-docker/28.3.3.sh",
  ]

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

29 марта 2024

Не стоит доверять встроенной проверке обновлений GitLab

В GitLab есть встроенная проверка на доступность новой версии, которая ещё и рассказывает о критичности такого обновления. Но эта проверка адекватно работает только для поддерживаемых версий.

Пример: есть инсталляция GitLab CE 16.7.7 и недавняя рассылка GitLab Security Release: 16.10.1, 16.9.3, 16.8.5. Там упоминаются CVE-2023-6371 (High) и CVE-2024-2818 (Medium) которым подвержены все версии до 16.8.5.

При этом в дашборде показывает только "Update available", а не "Update ASAP"

Т.е. не стоит доверять этому виджету если вы не используете последнюю версию GitLab. Ещё не хватает сообщения о неподдерживаемой версии.


Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

26 мая 2023

GitLab CI не выполняет after_script при таймауте

На днях столкнулся с очень старой проблемой (открыта 6 лет назад) в GitLab CI когда after_script не выполняется если джоба отвалилась по таймауту. В моём случае в after_script реализован сбор логов эфемерного окружения для end-to-end теста. Ирония в том что при успешном прохождении теста эти логи, как правило, никто не смотрит. А вот если тест упал, то начинают разбираться, а логов нету...

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

Второй мыслью был timeout из coreutils:

$ timeout --kill-after=350s 300s ./test.sh

В принципе эта утилита не должна оставлять "осиротевших" процессов, но если запуск происходит вне контейнера, то дополнительно можно добавить systemd-run:

$ timeout --kill-after=350s 300s systemd-run --user --pty --same-dir --wait --collect ./test.sh

На следующей неделе попробую внедрить в один из проектов и посмотреть.


Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

31 марта 2023

Решение проблемы "sysctl: permission denied" при обновлении GitLab

У меня GitLab живёт в непривилегированном контейнере LXC и при очередной установке обновления появились ошибки связанные с отсутсвием прав менять настройки sysctl. Это ожидаемое поведение, т.к. на сервере много других контейнеров и я не хочу чтобы каждый из них мог крутить настройки ядра.

Ошибки выглядят пример так

  * gitlab_sysctl[kernel.sem] action create
    * directory[create /etc/sysctl.d for kernel.sem] action create (up to date)
    * file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] action create[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] backed up to /opt/gitlab/embedded/cookbooks/cache/backup/opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf.chef-20230331221328.890308
[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] updated file contents /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf

      - update content in file /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf from 09a346 to 3b0a60
      --- /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf    2017-06-21 13:47:53.000000000 +0300
      +++ /opt/gitlab/embedded/etc/.chef-90-omnibus-gitlab-kernel20230331-271264-19acez0.sem.conf       2023-03-31 22:13:28.886738600 +0300
      @@ -1 +1 @@
      -kernel.sem = 250 32000 32 262
      +kernel.sem = 250 32000 32 275
    * link[/etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf] action create (up to date)
    * execute[load sysctl conf kernel.sem] action nothing (skipped due to action :nothing)
[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] sending run action to execute[load sysctl conf kernel.sem] (delayed)
    * execute[load sysctl conf kernel.sem] action run
      [execute] sysctl: permission denied on key "kernel.sem"

Чтобы избежать попыток "крутить" настройки ядра достаточно добавить параметр package['modify_kernel_parameters'] = false в /etc/gitlab/gitlab.rb и выполнить обновление конфигурации

$ cat <<_EOF_ | sudo tee -a /etc/gitlab/gitlab.rb
gitlab_kas['enable'] = false
_EOF_

$ sudo gitlab-ctl reconfigure

$ sudo gitlab-ctl restart

Перезапускать сервис не обязательно, но в моем случае часть сервисов оказались остановленными. Решение подсмотрел тут.


Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

18 ноября 2022

Nginx запрашивает / вместо /.well-known/openid-configuration

Настраиваю workload identity federation между on-prem GitLab и GCP согласно документации. Сделал настройки в GCP, взял готовый пример пайплайна, но джоба падает с ошибкой

$ gcloud auth print-access-token
ERROR: (gcloud.auth.print-access-token) ("Error code invalid_grant: Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected '{']", '{"error":"invalid_grant","error_description":"Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected \'{\']"}')

Смотрю что выдаёт https://GITLAB/.well-known/openid-configuration и вижу 302 редирект на /users/sign_in - это неожиданное поведение. На этот запрос должно возвращать JSON вида

$ curl -s https://gitlab.com/.well-known/openid-configuration
{"issuer":"https://gitlab.com","authorization_endpoint":"https://gitlab.com/oauth/authorize","token_endpoint":"https://gitlab.com/oauth/token","revocation_endpoint":"https://gitlab.com/oauth/revoke","introspection_endpoint":"https://gitlab.com/oauth/introspect","userinfo_endpoint":"https://gitlab.com/oauth/userinfo","jwks_uri":"https://gitlab.com/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}

Нужно разобраться откуда у меня берется этот редирект.

09 августа 2018

Сломалась LDAP аутентификация после обновления GitLab

После обновления GitLab с версии 9.5.10 до 10.8.7 столкнулся с ошибкой при входе с использованием LDAP аутентификации

Could not authenticate you from Ldapmain because "Ssl connect returned=1 errno=0 state=error: certificate verify failed".

Чтобы решить эту проблему нужно отредактировать файл /etc/gitlab/gitlab.rb и добавить параметр ca_file в секции настроек LDAP