release please
v16.15.0
Release Please는 프로젝트의 CHANGELOG 생성, GitHub 릴리스 생성 및 버전 범프를 자동화합니다.
git 기록을 구문 분석하고, 기존 커밋 메시지를 찾고, 릴리스 PR을 생성하여 이를 수행합니다.
패키지 관리자에 대한 게시를 처리하거나 복잡한 분기 관리를 처리하지 않습니다.
기본 브랜치에 도착한 것을 지속적으로 릴리스하는 대신 release-please는 릴리스 PR을 유지합니다.
추가 작업이 병합되면 이러한 릴리스 PR이 최신 상태로 유지됩니다. 릴리스에 태그를 지정할 준비가 되면 릴리스 PR을 병합하기만 하면 됩니다. 스쿼시 병합 및 병합 커밋은 모두 릴리스 PR에서 작동합니다.
Release PR이 병합되면 release-please는 다음 단계를 수행합니다.
다른 언어별 파일(예: package.json )과 함께 변경 로그 파일(예: CHANGELOG.md )을 업데이트합니다.
버전 번호로 커밋에 태그를 지정합니다.
태그를 기반으로 GitHub 릴리스를 생성합니다.
PR 자체의 상태 레이블을 통해 릴리스 PR의 수명 주기 위치를 알 수 있습니다.
autorelease: pending 릴리스 PR이 병합되기 전의 초기 상태입니다.
autorelease: tagged 릴리스 PR이 병합되었고 릴리스가 GitHub에 태그 지정되었음을 의미합니다.
autorelease: snapshot 은 스냅샷 버전 범프에 대한 특수 상태입니다.
autorelease: published GitHub 릴리스가 릴리스 PR을 기반으로 게시되었음을 의미합니다( release-please는 이 태그를 자동으로 추가하지 않지만 게시 도구 규칙으로 권장합니다 ).
릴리스에서는 기존 커밋 메시지를 사용하고 있다고 가정합니다.
염두에 두어야 할 가장 중요한 접두사는 다음과 같습니다.
fix: 버그 수정을 나타내며 SemVer 패치와 연관됩니다.
feat: 새로운 기능을 나타내며 SemVer 마이너와 연관됩니다.
feat!: , 또는 fix!: , refactor!: 등은 주요 변경 사항( ! 로 표시됨)을 나타내며 SemVer major가 됩니다.
풀 요청을 병합할 때 스쿼시 병합을 사용하는 것이 좋습니다 . 선형 Git 기록을 사용하면 다음 작업이 훨씬 쉬워집니다.
기록 따르기 - 커밋은 병합 날짜별로 정렬되며 풀 요청 간에 혼합되지 않습니다.
버그 찾기 및 되돌리기 - git bisect 버그가 발생한 변경 사항을 추적하는 데 유용합니다.
릴리스를 제어하세요. 변경 로그를 작성하세요. PR을 병합할 때 PR 범위 내에서는 의미가 있지만 기본 분기에서 병합할 때는 의미가 없는 커밋 메시지가 있을 수 있습니다. 예를 들어 feat: introduce feature A 후 fix: some bugfix introduced in the first commit 있을 수 있습니다. fix 커밋은 실제로 릴리스 노트와 관련이 없습니다. 메인 브랜치에서는 버그가 한번도 발생하지 않았기 때문입니다.
깨끗한 메인 브랜치를 유지하세요 - 레드/그린 개발(커밋 A에서 실패한 테스트를 만든 다음 커밋 B에서 수정) 및 병합(또는 리베이스-병합)과 같은 것을 사용하는 경우 메인 브랜치에 특정 시점이 있을 것입니다. 테스트가 통과되지 않는 곳.
Release Please를 사용하면 바닥글을 사용하여 단일 커밋에서 여러 변경 사항을 나타낼 수 있습니다.
feat: 암호화폐에 v4 UUID 추가 이는 v4 UUID에 대한 지원을 라이브러리에 추가합니다. 수정(utils): 유니코드에서 더 이상 예외가 발생하지 않습니다. PiperOrigin-RevId: 345559154 주요 변경: 인코딩 방법이 더 이상 발생하지 않습니다. 소스 링크: googleapis/googleapis@5e0dcb2 feat(utils): 유니코드를 지원하도록 인코딩 업데이트 PiperOrigin-RevId: 345559182 소스 링크: googleapis/googleapis@e5eef86
위의 커밋 메시지에는 다음이 포함됩니다.
"암호화에 v4 UUID 추가" 기능에 대한 항목입니다.
"유니코드가 더 이상 예외를 발생시키지 않음" 수정에 대한 항목과 이것이 주요 변경 사항이라는 메모가 함께 표시됩니다.
"유니코드를 지원하도록 인코딩 업데이트" 기능에 대한 항목입니다.
메인 브랜치에 대한 커밋의 커밋 본문 에 Release-As: xxx (대소문자 구분 안 함)가 있는 경우 Release Please는 지정된 버전에 대한 새 풀 요청을 엽니다.
빈 커밋 예:
git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0" 다음 커밋 메시지가 표시됩니다.
집안일: 릴리스 2.0.0 릴리스 이름: 2.0.0
풀 요청을 병합했고 해당 커밋에 대한 릴리스 노트를 생성하는 데 사용된 커밋 메시지를 수정하려는 경우 병합된 풀 요청의 본문을 편집하고 다음과 같은 섹션을 추가할 수 있습니다.
BEGIN_COMMIT_OVERRIDE feat: add ability to override merged commit message fix: another message chore: a third message END_COMMIT_OVERRIDE
다음에 Release Please가 실행되면 병합된 커밋 메시지 대신 해당 재정의 섹션을 커밋 메시지로 사용합니다.
Release Please는 마지막 릴리스 이후 기본 브랜치에 "릴리스 가능한 단위"가 포함되어 있음을 확인한 후 릴리스 풀 요청을 생성합니다. 릴리스 가능한 단위는 "feat", "fix" 및 "deps" 접두사 중 하나가 있는 브랜치에 대한 커밋입니다. ("자기 작업" 또는 "빌드" 커밋은 해제 가능한 단위가 아닙니다.)
일부 언어에는 특정 릴리스 가능 장치 구성이 있습니다. 예를 들어 "docs"는 Java 및 Python에서 릴리스 가능한 단위의 접두사입니다.
autorelease: pending 또는 autorelease: triggered autorelease: pending 또는 autorelease: triggered 레이블이 붙은 기존 풀 요청을 확인하세요. GitHub API 오류로 인해 이전 릴리스에서 태그가 올바르게 제거되지 않았을 수 있으며 Release Please는 이전 릴리스가 아직 보류 중이라고 생각합니다. 보류 중인 릴리스가 없다고 확신하는 경우 autorelease: pending 또는 autorelease: triggered 레이블을 제거하세요.
GitHub 애플리케이션 사용자의 경우, autorelease: pending 라는 라벨이 붙은 기존 풀 요청이 있는 경우 Release Please가 새 풀 요청을 생성하지 않습니다. 이 사례를 확인하려면 레이블이 있는 풀 요청을 검색하세요. (최신 릴리스 풀 요청일 가능성이 높습니다.) 레이블이 있는 릴리스 풀 요청을 찾았는데 릴리스되지 않을 예정인 경우(또는 이미 릴리스됨) autorelease: pending 레이블을 제거하고 릴리스를 다시 실행하세요.
릴리스 가능한 단위가 포함된 풀 요청이 병합된 후 Release Please가 릴리스 PR 생성을 놓쳤다고 생각되면 release-please 다시 실행하세요. GitHub 애플리케이션을 사용하는 경우 병합된 풀 요청에 release-please:force-run 라벨을 추가하세요. 작업을 사용하는 경우 실패한 호출을 찾아 워크플로 실행을 다시 시도하세요. Release Please는 풀 요청을 즉시 처리하여 릴리스 가능한 단위를 찾습니다.
Release Please는 다음과 같은 저장소에 대한 릴리스를 자동화합니다.
| 릴리스 유형 | 설명 |
|---|---|
bazel | MODULE.bazel 및 CHANGELOG.md가 포함된 Bazel 모듈 |
dart | pubspec.yaml 및 CHANGELOG.md가 있는 저장소 |
elixir | mix.exs 및 CHANGELOG.md가 있는 저장소 |
go | CHANGELOG.md가 있는 저장소 |
helm | Chart.yaml 및 CHANGELOG.md가 있는 저장소 |
java | 각 릴리스 이후 SNAPSHOT 버전을 생성하는 전략 |
krm-blueprint | 하나 이상의 KRM 파일과 CHANGELOG.md가 포함된 kpt 패키지 |
maven | Maven 프로젝트를 위한 전략, 각 릴리스 후에 SNAPSHOT 버전을 생성하고 pom.xml 자동으로 업데이트합니다. |
node | package.json 및 CHANGELOG.md가 포함된 Node.js 저장소 |
expo | package.json, app.json 및 CHANGELOG.md가 포함된 Expo 기반 React Native 저장소 |
ocaml | 하나 이상의 opam 또는 esy 파일과 CHANGELOG.md를 포함하는 OCaml 저장소 |
php | 작곡가.json 및 CHANGELOG.md가 있는 저장소 |
python | setup.py, setup.cfg, CHANGELOG.md 및 선택적으로 pyproject.toml 및 <project>/__init__.py가 포함된 Python 저장소 |
ruby | version.rb 및 CHANGELOG.md가 있는 저장소 |
rust | Cargo.toml(크레이트 또는 작업공간으로, 작업공간에는 매니페스트 기반 릴리스와 "cargo-workspace" 플러그인이 필요하다는 점에 유의) 및 CHANGELOG.md가 있는 Rust 저장소 |
sfdx | sfdx-project.json 및 CHANGELOG.md가 있는 저장소 |
simple | version.txt 및 CHANGELOG.md가 있는 저장소 |
terraform-module | README.md 버전과 CHANGELOG.md가 포함된 Terraform 모듈 |
릴리스를 배포할 수 있는 방법은 다양합니다.
Release Please를 실행하는 가장 쉬운 방법은 GitHub 작업을 사용하는 것입니다. 설치 및 구성 지침은 googleapis/release-please-action을 참조하세요.
모든 구성 옵션은 실행 중인 릴리스 - CLI를 참조하세요.
Release Please를 GitHub 앱으로 배포할 수 있는 프로토타입 애플리케이션이 있습니다. 설치 및 구성 지침은 github.com/googleapis/repo-automation-bots를 참조하세요.
릴리스 마지막 릴리스 태그 이후의 커밋을 살펴보세요. 이전 릴리스를 찾을 수도 있고 찾지 못할 수도 있습니다. 저장소를 온보딩하는 가장 쉬운 방법은 매니페스트 구성을 부트스트랩하는 것입니다.
릴리스는 릴리스 프로세스를 사용자 정의할 수 있는 여러 구성 옵션을 제공합니다. 자세한 내용은customizing.md를 참조하세요.
Release Please는 동일한 저장소에서 여러 아티팩트 릴리스도 지원합니다. 매니페스트-releaser.md에서 자세한 내용을 확인하세요.
우리의 클라이언트 라이브러리는 Node.js 릴리스 일정을 따릅니다. 라이브러리는 Node.js의 모든 현재 활성 및 유지 관리 버전과 호환됩니다.
Node.js의 일부 수명 종료 버전을 대상으로 하는 클라이언트 라이브러리를 사용할 수 있으며 npm dist-tags를 통해 설치할 수 있습니다. dist-tag는 명명 규칙 legacy-(version) 따릅니다.
레거시 Node.js 버전은 최선의 노력으로 지원됩니다.
레거시 버전은 지속적인 통합에서 테스트되지 않습니다.
일부 보안 패치는 백포트되지 않을 수 있습니다.
종속성은 최신 상태로 유지되지 않으며 기능은 백포트되지 않습니다.
legacy-8 : Node.js 8과 호환되는 버전의 경우 이 dist-tag에서 클라이언트 라이브러리를 설치합니다.
이 라이브러리는 Semantic Versioning을 따릅니다.
기여를 환영합니다! 기여 가이드를 참조하세요.
라이브러리 디자인에 대한 자세한 내용은 디자인을 참조하세요.
일반적인 문제와 구성 문제 해결에 대한 도움말은 문제 해결을 참조하세요.
아파치 버전 2.0
라이센스 보기
이것은 공식 Google 제품이 아닙니다.
