Логирование в проекте

Логирование в проекте#

Общий обзор#

GSF CLI записывает события и ошибки автоматически. Дополнительная настройка для обычной работы не нужна. Пользователь, запускающий команду, должен иметь право записи в workspace/logs внутри установки CLI.

Структура логирования#

Каталог workspace/logs создаётся при запуске. Он общий для проектов этой установки GSF CLI.

  • cmd_error_log.txt — скрипты config.sh/config.cmd и manage.sh/manage.cmd добавляют сюда время запуска, команду и её stderr. Некоторые ярлыки также используют этот файл. Прямой запуск .py, credential_manager и gsf_git не перенаправляет stderr в него этими скриптами.

  • YYYY-MM-DD.log — сообщения Python-части CLI. Запись содержит время, уровень, текст, имя функции и номер строки. Необработанные исключения записываются со стеком вызовов. Сообщения уровня ERROR и выше также выводятся в stdout.

Для ежедневного лога настроена ротация в полночь с backupCount=10. При этом имя основного файла выбирается по дате каждого нового процесса. Это не гарантирует удаление всех файлов каталога старше десяти дней. cmd_error_log.txt дописывается без настроенной ротации; контролируйте его размер отдельно.

Пример структуры каталога логов#

project_root/
├── workspace/
│   ├── logs/
│   │   ├── cmd_error_log.txt
│   │   ├── 2025-03-01.log
│   │   ├── 2025-03-02.log
│   │   ├── ...
│   │   ├── 2025-03-10.log

Где искать причину ошибки#

Найдите последний запуск нужной команды в cmd_error_log.txt, затем откройте ежедневный лог за ту же дату. Смотрите первую ошибку перед завершением сборки: последующие сообщения могут быть её следствием.

Для manage.sh на Linux можно вывести stderr в терминал вместо перенаправления:

NO_STDERR_REDIRECT=1 ./manage.sh -p main refresh

Ежедневный Python-лог при этом продолжает записываться. У Windows-обёртки manage.cmd такого переключателя нет.

Не передавайте пароль в аргументах команд, которые могут записываться в журнал. Для credential manager используйте --password-stdin, а для просмотра записей — show без --reveal. В GitLab не включайте CI_DEBUG_TRACE и не печатайте окружение job с секретами.

Подробный лог SBT#

Для ошибки при подготовке dev-зависимостей запустите publishDevDependencies с параметром -debug. В Windows откройте CMD и выполните:

cd /d "C:\programs\gsf-cli\workspace\links\main"
sbt.cmd -debug "publishDevDependencies"

В Linux:

cd /opt/global/gsf-cli/workspace/links/main
./sbt.sh -debug "publishDevDependencies"

Замените путь к GSF CLI и имя main своими значениями. Используется ярлык конкретного проекта, который уже подготовлен через мастер. Окружение доступа к закрытым репозиториям должно быть настроено до запуска. Для headless без ярлыков порядок запуска через set_env описан в главах Linux и Windows.

Этот вызов показывает подробный вывод SBT прямо в консоли; обёртка manage в нём не участвует. Параметр -debug принимает SBT, у manage build его нет. Подробности уровней вывода — в документации SBT.

Содержание