Вышел Gitea 1.27, легковесная платформа для самостоятельного хостинга Git с открытым кодом, ориентированная на простоту.

Ключевым изменением стала улучшенная обработка повторно используемых рабочих процессов Actions. Рабочие процессы, на которые ссылаются через директиву uses:, теперь парсятся напрямую Gitea: каждый вызываемый процесс разворачивается в отдельные задания. Эти задания получают собственные записи на боковой панели запуска, отдельные журналы и отдельные узлы в графе зависимостей, что упрощает поиск сбоев внутри повторно используемых процессов.

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

В Gitea Actions появилась поддержка сводок заданий через переменную окружения GITHUB_STEP_SUMMARY. Шаги рабочих процессов могут записывать Markdown-содержимое в этот файл, и Gitea отображает его прямо на странице сводки запуска, а не сохраняет как загружаемый артефакт.

Кроме того, исправлена поддержка jobs.<job_id>.continue-on-error. Ранее Gitea обрабатывал этот параметр, но все равно помечал весь рабочий процесс как неудачный при сбое разрешенного задания. Версия 1.27 теперь корректно учитывает такие ошибки при определении итогового статуса процесса.

Отменённые рабочие процессы также обрабатываются более предсказуемо. Gitea теперь может выполнять шаги очистки после завершения и условия с always() или cancelled() перед тем, как пометить задание как отменённое. Сводки заданий, промежуточное состояние отмены и корректная обработка continue-on-error требуют свежего Gitea Runner 2.0. Старые версии раннера сохраняют совместимость, но не поддерживают эти возможности.

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

Кроме улучшений в Actions, в Gitea 1.27 появился встроенный рендеринг файлов Jupyter Notebook. Файлы с расширением .ipynb теперь отображаются как отформатированные блокноты с включением сгенерированного вывода, а не в виде сырого JSON.

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

Среди других улучшений репозиториев и совместной работы: компактные стопки аватаров, расширенная подсветка синтаксиса для огороженных блоков кода Markdown, поиск по спискам участников организаций и видимость команд организаций. Администраторы теперь могут устанавливать раздельные лимиты на создание репозиториев для личных учетных записей и организаций.

В части API Gitea теперь публикует спецификацию OpenAPI 3.0 по адресу /openapi.v1.json, что упрощает генерацию клиентского кода и интеграцию с внешними инструментами разработки. Также добавлены эндпоинты для проверки текущего токена доступа, позволяющие токену удалить самого себя, управлять назначенными исполнителями задач и запросов на слияние, а также получать список запусков, связанных с конкретным рабочим процессом.

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

Подробнее см. в анонсе. Как обычно, перед обновлением рекомендуется сделать резервную копию данных: замените исполняемый файл или Docker-контейнер и перезапустите службу.