02.10.2025 10:23
cool4uma 0 210 Источник

При работе с поддержкой GitLab, будь то установка из Omnibus пакета или Docker-контейнер, иногда приходится запускать руки в консоль gitlab-rails. Причин тому может быть много в зависимости от версии GitLab и задач, стоящих перед вами, например, чистка артефактов, исправление ошибок блокирующих обновление, или массовые операции с проектами/пользователями/токенами и так далее. Некоторые такие задачи может потребоваться запускать регулярно, и как раз на примере одной из них мы и попробуем написать Cron-задание для Sidekiq.

Наш пример

Как известно, в версии 16.0 gitlab удалил поддержку бессрочных токенов доступа. Многих пользователей Self-Managed установок GitLab эта мера расстроила. Например, без токена доступа нельзя получить доступ по API к публичным репозиториям, хотя эти репозитории доступны для чтения без аутентификации. Но, к счастью, через консоль gitlab-rails можно найти нужные токены и обновить их срок действия.

myToken = PersonalAccessToken.where(name: "myTokenName")         

myToken.update!(expires_at: 365.days.from_now)                     

Имена токенов, которые мы хотим продлевать, имеют определенный префикс — "noExpiration-".


Итак, наша цель — сделать бессрочные токены, а если точнее, то автоматизировать обновление их срока действия.

Задание в Sidekiq

Чтобы создать задание в Sidekiq, нам необходимо определить класс Worker, который мы будем использовать для постановки задания в очередь, и метод perform внутри этого класса. Метод perform будет отбирать и обновлять токены доступа. Согласно документации GitLab, все рабочие процессы вместо Sidekiq::Worker должны включать ApplicationWorker, который содержит дополнительные методы и автоматически устанавливает очередь маршрутизации.

Запускаем gitlab-rails console и пишем наш класс:

class AutoExtendTokens  

    include ApplicationWorker  

        def perform  

            targetTokens = PersonalAccessToken.active.where("name LIKE ?", "%noExpiration-%")

            targetTokens.update!(expires_at: 365.days.from_now)

        end  

end

После этого можем завести пару тестовых токенов, вызвать метод perform из нашего класса и проверить, все ли работает. Для этого пишем AutoExtendTokens.new.perform().Если все сделали верно, то должны получить обновленные токены, срок которых истекает через 12 месяцев.

Далее создаем задание в Cron, в рамках теста пусть будет на каждые 5 минут, чтобы не томить нас в ожиданиях результата.
Sidekiq::Cron::Job.create(name: 'Auto-Extend-Tokens - every 5min', cron: '*/5 * * * *', class: 'AutoExtendTokens')

Если мы сделали все верно, то задание сразу же отобразится в панели управления Sidekiq, но работать не будет ?.

После первого же запуска мы получим ошибку следующего содержания: uninitialized constant AutoExtendTokens. Когда мы чуть выше тестировали наш класс, он был нам доступен, так как писали его в той же сессии gitlab-rails, но в текущей среде выполнения Sidekiq он недоступен. 

Чтобы исправить эту ошибку, нужно добавить класс в автозагрузку. Для этого создаем на сервере GitLab файл auto_extend_tokens.rb в директории /opt/gitlab/embedded/service/gitlab-rails/app/models/ . Важно дать правильное имя файлу *.rb — если у вас класс называется MyTestClass, то имя файла должно быть my_test_class.rb. Далее перезагружаем gitlab-rails и gitlab-sidekiq, а если есть возможность, то лучше всего перезагрузить все.

Заключение

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

Продление токенов доступа лишь один из примеров задач. В контексте GitLab, Sidekiq играет ключевую роль, обеспечивая асинхронное выполнение различных задач. Это позволяет основному приложению GitLab оставаться отзывчивым, не блокируя пользовательские запросы длительными операциями.  

Комментарии (0)