выпуски
SubLane Оригинальное название: Releases.
The Release Рабочий процесс начинается, когда консьерж толкает v* Нет автоматического релиза на обычных ветвях pushs или pull requests.
Версийный контракт
Использование канонических тегов, таких как v0.1.0 или v0.1.0-rc.1Версия приложения и Docker Тег версии опускает ведущий v. Ведущие нулевые числовые компоненты, белое пространство, символы оболочки и метаданные сборки SemVer+...Предвыпускные числовые идентификаторы также должны быть каноническими.
Каждый выпуск включает в себя:
sublane_VERSION_linux_amd64.tar.gzиsublane_VERSION_linux_arm64.tar.gz.docker.compose.yamlиSHA256SUMSПубличные файлы релизов.- Многоплатформенный
ghcr.io/murongg/sublane:VERSIONИзображение, плюс два архитектурных тега. - Сохраните заметки о выпуске Changelog, созданные из истории Git, с прикрепленным git-cliff 2.14.2.
Только самый высокий стабильный тег версии, присутствующий в настоящее время в репозитории, может обновить Docker latest канал и GitHubОбозначение последнего выпуска. Предвыпуск или более старая версия обслуживания никогда не перемещает эти каналы назад. Если сборка самого высокого стабильного тега не удалась, повторите этот выпуск; более низкие теги намеренно не занимают его место. Развертывания должны закреплять версию или переваривать, а не полагаться на latest.
Настройка репозитория в первый раз
Рабочий процесс использует GITHUB_TOKENсферой применения для contents: write и packages: write только в издательской работе. Не нуждается в Docker Учетная запись Hub или персональный токен доступа. GitHub Действия и публикация пакета GHCR должны быть разрешены политикой репозитория / организации. Все зависимости от действий прикреплены к полному SHA.
Ярлык источника репозитория связывает изображение с репозиторием. Пакеты GHCR изначально могут быть приватными даже для репозитория с открытым исходным кодом. После первой успешной публикации проверьте настройки доступа пакета и сделайте его общедоступным, если предназначены анонимные тяги. См. GitHub? Документация реестра контейнеровСохраняйте опубликованные пакеты, связанные с этим хранилищем, чтобы последующие рабочие процессы сохраняли доступ к записи.
Опубликовать версию
Создавать и анализировать CHANGELOG.md В вашем отделе развития с make changelog, затем соединяйте его с документацией, обращенной к выпуску. Сначала объединяйте эти изменения и рабочий процесс выпуска и запускайте make checkВыберите новую неиспользуемую версию; не перемещайте существующий тег выпуска.
Например, после выбора v0.1.0:
git switch main
git pull --ff-only
make publish-check TAG=v0.1.0
make publish TAG=v0.1.0make publish-check Запускает тот же самый предполет, не создавая и не нажимая тег. make publish создает аннотированный тег на проверяемом фиксе и нажимает только этот тег. Оба требуют чистого рабочего дерева (включая неотслеженные файлы), main ветвь, существующий рабочий процесс высвобождения в этом обязательстве, и точно один origin Тяжёлый путь, чей main Локальные или удаленные дубликаты тегов отклоняются. Никакая ветвь не переключается, не сливается и не толкается автоматически.
Тег определяет тип выпуска; не требуется отдельного флага предварительного выпуска:
make publish TAG=v0.1.0-rc.1Вы также можете бегать node scripts/publish.mjs v0.1.0 --dry-run или node scripts/publish.mjs v0.1.0 Непосредственно из репозитория. требуются Node.js 24 и Git, с рабочими учетными данными Git push (например, агент SSH); Docker Удостоверения хаба не требуются. Сценарий проверяет удаленный тег после нажатия и печатает GitHub Ссылка рабочего процесса действий, когда настроенный пульт дистанционного управления использует распознаваемый GitHub URL.
Если толчок не удается или его результат не может быть проверен, локальный тег сохраняется, потому что пульт, возможно, уже принял его. Сначала проверьте пульт и Действия. Если пульт отсутствует, используйте команду однотеговой повторной записи, напечатанную скриптом. Он никогда не удаляет теги или форс-толчки. Скрипт запускает существующий конвейер CI; он не сообщает о сборках или публикации как завершенные только потому, что толчок тега преуспел.
Примерная версия иллюстративна. Опубликуйте одну выбранную версию за раз и проверьте результат Действий, прежде чем объявлять о доступности. Нажатие тега версии является триггером публикации; рабочий процесс создает GitHub Освободите себя.
Последовательность рабочих процессов
- Проверить тег и вычислить нижнюю строчку GHCR путь изображения от имени репозитория.
- Позвоните по обычному рабочему процессу CI: проверка дрейфа sqlc, тесты Go / Vet, проверки / сборка интерфейса, тесты метаданных и Compose валидация.
- Строить и тестировать дым Docker Изображение на родных Linux amd64 и arm64 раннерах. На PR и релизах извлекайте фактический двоичный файл из каждого протестированного изображения, упаковывайте его с файлами развертывания и уведомлениями о лицензиях, затем распаковывайте и выполняйте его для проверки версии. Запуски выпуска также сохраняют оба протестированных изображения как недолговечные артефакты Actions.
- После того, как все чеки пройдут, возьмите полную помеченную историю, создайте заметки о выпуске с
cliff.tomlСоздать или возобновить проект GitHub Проект заметок регенерируется на повторе; ранее опубликованный релиз никогда не перезаписывается. - Загрузите и нажмите на эти протестированные изображения, а затем создайте тег мультиплатформенной версии. Во время публикации не происходит второй сборки приложения.
- Загрузить бинарные архивы, Compose и контрольные суммы SHA-256. Продвигайте новейший стабильный канал, когда это необходимо, а затем публикуйте завершенный релиз.
Версия/источник/редакция встроены в изображение и sublane --version Сообщает упакованная версия. Файловые системы корневого изображения содержат только утилиты альпийского времени выполнения, публичные сертификаты CA, двоичные и лицензионные уведомления. Ни один источник проверки, компилятор, зависимости Node.js или локальные данные не включены. Создание контекстного списка исключает локальные базы данных, ключи шифрования, резервные копии и рабочие деревья.
Неудачи и повторные попытки
Использовать Восстановление неудачных рабочих мест на рабочем процессе того же тега выполняется, когда сеть, сборка или операция реестра терпят неудачу. Перед завершением артефакты выпуска остаются в черновике и могут быть заменены повторным. Изображения пер-архитектуры/версии могут уже существовать, если более поздний шаг не удался; повторный выпуск завершает тот же выпуск. Публикация реестра и GitHub Выпуск не может быть одной атомной транзакцией, поэтому проверьте оба пункта назначения после сбоя.
Артефакты сохраняются в течение семи дней. По истечении срока действия перепроверить все рабочие места на реконструкцию и повторное тестирование. Перепроверки заменяют одноимённые артефакты Actions в этом прогоне; уже опубликованные GitHub После публикации релиза используйте новую версию для исправления кода или упаковки, а не перезаписывайте его. Удаление или перемещение тега не откатывает загруженные двоичные файлы, опубликованные изображения или развернутые базы данных.
GITHUB_TOKEN-созданные толчки тегов обычно не запускают другой рабочий процесс. Если другая автоматизация создает теги, используйте соответствующим образом GitHub Приложение/токен или запуск релиза через явно разработанный поток отправки. Ручное устройство поддерживает работу без этой дополнительной настройки. См. GitHub? Правила запуска рабочего процесса.
Местная упаковка
make release VERSION=0.0.0-testЭто создает интерфейс один раз, кросс-компилирует две двоичные файлы Linux и пишет архивы плюс. SHA256SUMS игнорируется dist/release/Существующие архивы не перезаписываются; используйте свежую тестовую версию или перемещайте ранее созданные артефакты перед восстановлением. Эта команда не толкает изображения или не создает выпуски. Держите локальную проверку сборки отдельно от нативных доказательств времени выполнения контейнера.
Поколение Changelog
устанавливать обрыв 2.14.2 (версия прикреплена в CI). Это инструмент разработки, а не зависимость от сервера. Например, при установке Rust, используйте cargo install git-cliff --locked --version 2.14.2Загруженный исполняемый файл может быть выбран через GIT_CLIFF=/path/to/git-cliff.
make changelog
make changelog-checkcliff.toml Использует заголовки Keep a Changelog: Added, Changed, Deprecated, Removed, Fixed and Security. Функции и исправления следуют обычным обязательствам; сборки, производительность и рефакторы изменены. Явные амортизационные/удаленные и защищенные изменения получают свои собственные разделы. Рутинные документы, тесты, стиль и обязанности опущены, при этом нарушение изменений и их объяснения остаются видимыми. Слияние сообщений и нетрадиционных обязательств исключены; просмотр генерируемого текста перед выпуском.
Поколение читает локальную историю Git с отключенными сетевыми метаданными и внешними командами шаблонов. CHANGELOG.md только после того, как рендеринг увенчается успехом, и не создает теги, не изменяет версии или не фиксирует файлы.Прежде чем запускать, загрузите сгенерированный файл через обычный поток PR make publishРепозиторий changelogs включает в себя разделы предварительного выпуска; примечания стабильного выпуска суммируют весь цикл с момента предыдущего стабильного тега, включая изменения, впервые внесенные в предварительные выпуски.
Для существующего тега, проверенного в HEAD:
make release-notes TAG=v0.1.0Об этом пишет dist/release-notes.md используя тот же шаблон; рабочий процесс выпуска устанавливает зажатый генератор, извлекает полную историю и передает этот файл GitHubОтклоняется отсутствующий или несоответствующий тег. CI запускает тесты интеграции синтетической истории; запускается make changelog-check локально, чтобы включить эти тесты при установке git-cliff. make check Они являются необязательными, если только SUBLANE_TEST_CHANGELOG=1 Ни одна из команд не меняет Чтение.