release please

กรุณาปล่อย

Release โปรดสร้าง CHANGELOG โดยอัตโนมัติ การสร้าง GitHub release และ version bumping สำหรับโปรเจ็กต์ของคุณ

โดยแยกวิเคราะห์ประวัติ Git ของคุณ ค้นหาข้อความ Conventional Commit และสร้าง PR สำหรับการเผยแพร่

ไม่รองรับการเผยแพร่ไปยังผู้จัดการแพ็คเกจหรือจัดการการจัดการสาขาที่ซับซ้อน

Release PR คืออะไร?

แทนที่จะปล่อยสิ่งที่ตกสู่สาขาเริ่มต้นของคุณอย่างต่อเนื่อง โปรดปล่อย PR ของรุ่นไว้:

ประชาสัมพันธ์การเผยแพร่เหล่านี้ได้รับการปรับปรุงให้ทันสมัยอยู่เสมอเมื่อมีการรวมงานเพิ่มเติมเข้าด้วยกัน เมื่อคุณพร้อมที่จะแท็กรุ่น เพียงผสาน PR รุ่นเข้าด้วยกัน ทั้งสควอชผสานและผสานคอมมิตทำงานร่วมกับ Release PR

เมื่อมีการรวม Release PR โปรดดำเนินการตามขั้นตอนต่อไปนี้:

1. อัปเดตไฟล์บันทึกการเปลี่ยนแปลงของคุณ (เช่น CHANGELOG.md ) พร้อมกับไฟล์เฉพาะภาษาอื่นๆ (เช่น package.json )

2. แท็กการคอมมิตด้วยหมายเลขเวอร์ชัน

3. สร้าง GitHub Release ตามแท็ก

คุณสามารถบอกได้ว่า Release PR อยู่ที่ใดในวงจรการใช้งานโดยป้ายสถานะบน PR เอง:

• autorelease: pending คือสถานะเริ่มต้นของ Release PR ก่อนที่จะถูกรวมเข้าด้วยกัน

• autorelease: tagged หมายความว่า Release PR ได้รับการรวมเข้าด้วยกันและ release ได้รับการติดแท็กใน GitHub

• autorelease: snapshot เป็นสถานะพิเศษสำหรับการกระแทกเวอร์ชันสแนปช็อต

• autorelease: published หมายความว่ามีการเผยแพร่ GitHub release ตาม Release PR ( release-please จะไม่เพิ่มแท็กนี้โดยอัตโนมัติ แต่เราขอแนะนำว่าเป็นแบบแผนสำหรับเครื่องมือการเผยแพร่ )

ฉันจะเขียนคอมมิตของฉันได้อย่างไร?

Release Please ถือว่าคุณกำลังใช้ข้อความ Conventional Commit

คำนำหน้าที่สำคัญที่สุดที่คุณควรมีในใจคือ:

• fix: ซึ่งแสดงถึงการแก้ไขข้อบกพร่องและสัมพันธ์กับแพตช์ SemVer

• feat: ซึ่งแสดงถึงคุณสมบัติใหม่และสัมพันธ์กับ SemVer minor

• feat!: หรือ fix!: , refactor!: ฯลฯ ซึ่งแสดงถึงการเปลี่ยนแปลงที่ไม่สมบูรณ์ (ระบุโดย ! ) และจะส่งผลให้เกิด SemVer major

ประวัติการคอมมิตเชิงเส้นคอมไพล์ (ใช้สควอชผสาน)

เราขอแนะนำ อย่างยิ่ง ให้คุณใช้การผสานสควอชเมื่อรวมคำขอดึงข้อมูล ประวัติคอมไพล์เชิงเส้นช่วยให้:

• ติดตามประวัติ - การคอมมิตจะถูกจัดเรียงตามวันที่รวมและไม่ปะปนกันระหว่างคำขอดึง

• ค้นหาและย้อนกลับข้อบกพร่อง - git bisect มีประโยชน์ในการติดตามว่าการเปลี่ยนแปลงใดทำให้เกิดข้อบกพร่อง

• ควบคุมบันทึกการเปลี่ยนแปลงโปรดเผยแพร่ - เมื่อคุณรวม PR คุณอาจส่งข้อความที่สมเหตุสมผลภายในขอบเขตของ PR แต่ไม่สมเหตุสมผลเมื่อรวมในสาขาหลัก ตัวอย่างเช่น คุณอาจมี feat: introduce feature A แล้ว fix: some bugfix introduced in the first commit จริงๆ แล้ว fix คอมมิตไม่เกี่ยวข้องกับบันทึกประจำรุ่น เนื่องจากไม่เคยพบจุดบกพร่องในสาขาหลัก

• รักษาสาขาหลักที่สะอาด - หากคุณใช้บางอย่างเช่นการพัฒนาสีแดง/เขียว (สร้างการทดสอบที่ล้มเหลวในการคอมมิต A จากนั้นแก้ไขในคอมมิต B) และผสาน (หรือรวมรีเบส) จากนั้นจะมีจุดตรงเวลาในสาขาหลักของคุณ ที่ซึ่งการทดสอบไม่ผ่าน

จะเกิดอะไรขึ้นหาก PR ของฉันมีการแก้ไขหรือฟีเจอร์หลายอย่าง

Release Please อนุญาตให้คุณแสดงการเปลี่ยนแปลงหลายอย่างในการคอมมิตเดียว โดยใช้ส่วนท้าย:

 ความสำเร็จ: เพิ่ม v4 UUID ให้กับ crypto

นี่เป็นการเพิ่มการรองรับ v4 UUID ให้กับไลบรารี

แก้ไข (ยูทิลิตี้): ยูนิโค้ดไม่ส่งข้อยกเว้นอีกต่อไป
  PiperOrigin-RevId: 345559154
  การเปลี่ยนแปลงที่แตกหัก: วิธีการเข้ารหัสจะไม่พ่นอีกต่อไป
  ลิงก์ที่มา: googleapis/googleapis@5e0dcb2

feat(utils): อัปเดตการเข้ารหัสเพื่อรองรับ Unicode
  PiperOrigin-RevId: 345559182
  ลิงก์ที่มา: googleapis/googleapis@e5eef86

ข้อความยืนยันข้างต้นจะประกอบด้วย:

1. รายการสำหรับคุณสมบัติ "เพิ่ม v4 UUID ให้กับ crypto"

2. รายการสำหรับการแก้ไข "unicode จะไม่ส่งข้อยกเว้นอีกต่อไป" พร้อมด้วยหมายเหตุว่าเป็นการเปลี่ยนแปลงที่ไม่สมบูรณ์

3. รายการสำหรับคุณลักษณะ "อัปเดตการเข้ารหัสเพื่อรองรับ Unicode"

สำคัญ: ต้องเพิ่มข้อความเพิ่มเติมที่ด้านล่างของการคอมมิต

ฉันจะเปลี่ยนหมายเลขเวอร์ชันได้อย่างไร

เมื่อคอมมิตในสาขาหลักมี 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 bot ไม่ได้สร้าง PR รุ่น ทำไม

ขั้นตอนที่ 1: ตรวจสอบให้แน่ใจว่าได้รวมยูนิตที่ปล่อยได้เข้าด้วยกัน

Release โปรดสร้างคำขอดึงรุ่นหลังจากสังเกตเห็นว่าสาขาเริ่มต้นมี "หน่วยที่วางจำหน่ายได้" ตั้งแต่รุ่นล่าสุด ยูนิตที่รีลีสได้คือการคอมมิตต่อสาขาด้วยคำนำหน้าอย่างใดอย่างหนึ่งต่อไปนี้: "feat", "fix" และ "deps" (การคอมมิต "งานบ้าน" หรือ "บิลด์" ไม่ใช่หน่วยที่รีลีสได้)

บางภาษามีการกำหนดค่าหน่วยที่สามารถเผยแพร่ได้เฉพาะ ตัวอย่างเช่น "docs" เป็นคำนำหน้าสำหรับหน่วยที่เผยแพร่ได้ใน Java และ Python

ขั้นตอนที่ 2: ตรวจสอบให้แน่ใจว่าไม่มี autorelease: pending หรือ autorelease: triggered ใน PR เก่า

ตรวจสอบคำขอดึงที่มีอยู่ซึ่งมีป้ายกำกับว่า autorelease: pending หรือ autorelease: triggered label เนื่องจากความล้มเหลวของ GitHub API จึงเป็นไปได้ว่าแท็กไม่ได้ถูกลบอย่างถูกต้องในรุ่นก่อนหน้าและรุ่นโปรดคิดว่ารุ่นก่อนหน้ายังคงค้างอยู่ หากคุณแน่ใจว่าไม่มีการเผยแพร่ที่รอดำเนินการ ให้ลบป้ายกำกับ autorelease: pending หรือ autorelease: triggered

สำหรับผู้ใช้แอปพลิเคชัน GitHub Release Please จะไม่สร้างคำขอดึงใหม่ หากมีคำขอดึงที่มีอยู่ซึ่งมีป้ายกำกับว่า autorelease: pending เพื่อยืนยันกรณีนี้ ให้ค้นหาคำขอดึงที่มีป้ายกำกับ (เป็นไปได้มากว่ามันจะเป็นคำขอดึงรีลีสล่าสุด) หากคุณพบคำขอดึงรีลีสที่มีป้ายกำกับ และมันจะไม่ถูกรีลีส (หรือรีลีสแล้ว) ให้ลบ autorelease: pending label แล้วรัน Release Please อีกครั้ง

ขั้นตอนที่ 3: กรุณารีรันรีลีสอีกครั้ง

หากคุณคิดว่า Release โปรดพลาดการสร้าง PR รุ่นหลังจากรวมคำขอดึงกับหน่วยที่วางจำหน่ายแล้ว โปรดเรียกใช้ release-please อีกครั้ง หากคุณใช้แอปพลิเคชัน GitHub ให้เพิ่มป้าย release-please:force-run ให้กับคำขอดึงแบบรวม หากคุณกำลังใช้การดำเนินการ ให้มองหาการเรียกใช้ที่ล้มเหลว และลองเรียกใช้เวิร์กโฟลว์อีกครั้ง Release Please จะดำเนินการตามคำขอดึงทันทีเพื่อค้นหายูนิตที่สามารถปล่อยได้

รองรับประเภทกลยุทธ์ (ภาษา)

Release Please ทำการเผยแพร่อัตโนมัติสำหรับที่เก็บรสชาติต่อไปนี้:

ประเภทการเปิดตัว	คำอธิบาย
bazel	โมดูล Bazel พร้อมด้วย MODULE.bazel และ CHANGELOG.md
dart	พื้นที่เก็บข้อมูลที่มี pubspec.yaml และ CHANGELOG.md
elixir	พื้นที่เก็บข้อมูลที่มี mix.exs และ CHANGELOG.md
go	พื้นที่เก็บข้อมูลที่มี CHANGELOG.md
helm	พื้นที่เก็บข้อมูลที่มี Chart.yaml และ CHANGELOG.md
java	กลยุทธ์ที่สร้างเวอร์ชัน SNAPSHOT หลังจากแต่ละรุ่น
krm-blueprint	แพ็คเกจ kpt ที่มีไฟล์ KRM 1 ไฟล์ขึ้นไปและ CHANGELOG.md
maven	กลยุทธ์สำหรับโปรเจ็กต์ Maven สร้างเวอร์ชัน SNAPSHOT หลังจากแต่ละรีลีส และอัปเดต pom.xml โดยอัตโนมัติ
node	พื้นที่เก็บข้อมูล Node.js พร้อมด้วย package.json และ CHANGELOG.md
expo	พื้นที่เก็บข้อมูล React Native ที่ใช้ Expo พร้อมด้วย package.json, app.json และ CHANGELOG.md
ocaml	พื้นที่เก็บข้อมูล OCaml ที่มีไฟล์ opam หรือ esy 1 ไฟล์ขึ้นไปและ CHANGELOG.md
php	พื้นที่เก็บข้อมูลที่มี composer.json และ CHANGELOG.md
python	พื้นที่เก็บข้อมูล Python ที่มี setup.py, setup.cfg, CHANGELOG.md และ pyproject.toml และ <project>/__init__.py เป็นทางเลือก
ruby	พื้นที่เก็บข้อมูลที่มี version.rb และ CHANGELOG.md
rust	พื้นที่เก็บข้อมูล Rust พร้อมด้วย Cargo.toml (ไม่ว่าจะเป็นลังหรือพื้นที่ทำงาน แม้ว่าโปรดทราบว่าพื้นที่ทำงานจำเป็นต้องมีการเผยแพร่ที่ขับเคลื่อนอย่างชัดแจ้งและปลั๊กอิน "cargo-workspace") และ CHANGELOG.md
sfdx	พื้นที่เก็บข้อมูลที่มี sfdx-project.json และ CHANGELOG.md
simple	พื้นที่เก็บข้อมูลที่มี version.txt และ CHANGELOG.md
terraform-module	โมดูล Terraform ซึ่งมีเวอร์ชันอยู่ใน README.md และ CHANGELOG.md

โปรดตั้งค่าการเผยแพร่

มีหลายวิธีที่คุณสามารถปรับใช้ release ได้โปรด:

GitHub Action (แนะนำ)

วิธีที่ง่ายที่สุดในการรัน Release Please คือการดำเนินการของ GitHub โปรดดู googleapis/release-please-action สำหรับคำแนะนำในการติดตั้งและการกำหนดค่า

ทำงานเป็น CLI

โปรดดูที่การรัน release-please CLI สำหรับตัวเลือกการกำหนดค่าทั้งหมด

ติดตั้งแอป GitHub

มีแอปพลิเคชัน probot ซึ่งช่วยให้คุณสามารถปรับใช้ Release Please เป็นแอป GitHub โปรดดู github.com/googleapis/repo-automation-bots สำหรับคำแนะนำในการติดตั้งและกำหนดค่า

การเริ่มต้นระบบ Repository ของคุณ

Release โปรดดูที่การคอมมิตตั้งแต่แท็กรีลีสครั้งล่าสุดของคุณ มันอาจจะหรืออาจจะไม่สามารถค้นหารุ่นก่อนหน้าของคุณ วิธีที่ง่ายที่สุดในการเริ่มใช้งานพื้นที่เก็บข้อมูลของคุณคือการบูตสแตรปการกำหนดค่ารายการ

กรุณาปรับแต่ง Release

โปรดเผยแพร่ตัวเลือกการกำหนดค่าหลายรายการเพื่อให้สามารถกำหนดกระบวนการเผยแพร่ของคุณได้เอง โปรดดูที่ customizing.md สำหรับรายละเอียดเพิ่มเติม

รองรับ Monorepos ผ่านการกำหนดค่า Manifest

Release Please ยังรองรับการรีลีสอาร์ติแฟกต์หลายรายการจากพื้นที่เก็บข้อมูลเดียวกัน ดูเพิ่มเติมที่ manifest-releaser.md

เวอร์ชัน Node.js ที่รองรับ

ไลบรารีลูกค้าของเราเป็นไปตามกำหนดการเปิดตัว Node.js ไลบรารีเข้ากันได้กับ Node.js เวอร์ชัน ที่ใช้งานอยู่ และเวอร์ชัน บำรุงรักษา ทั้งหมดในปัจจุบัน

ไลบรารีไคลเอ็นต์ที่กำหนดเป้าหมาย Node.js เวอร์ชันหมดอายุบางเวอร์ชันพร้อมใช้งาน และสามารถติดตั้งได้ผ่านแท็ก dist npm แท็ก dist เป็นไปตามหลักการตั้งชื่อ legacy-(version)

เวอร์ชัน Legacy Node.js ได้รับการรองรับอย่างดีที่สุด:

• เวอร์ชันเก่าจะไม่ได้รับการทดสอบในการผสานรวมอย่างต่อเนื่อง

• แพตช์รักษาความปลอดภัยบางตัวอาจไม่สามารถแบ็คพอร์ตได้

• การขึ้นต่อกันจะไม่ได้รับการอัปเดตให้ทันสมัย ​​และฟีเจอร์ต่างๆ จะไม่ถูกแบ็คพอร์ต

มีแท็กแบบเดิม

• legacy-8 : ติดตั้งไลบรารีไคลเอ็นต์จาก dist-tag นี้สำหรับเวอร์ชันที่เข้ากันได้กับ Node.js 8

การกำหนดเวอร์ชัน

ไลบรารีนี้เป็นไปตามการกำหนดเวอร์ชันเชิงความหมาย

มีส่วนร่วม

ยินดีต้อนรับการมีส่วนร่วม! ดูคู่มือการมีส่วนร่วม

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการออกแบบห้องสมุด โปรดดูการออกแบบ

การแก้ไขปัญหา

สำหรับปัญหาทั่วไปและความช่วยเหลือในการแก้ไขปัญหาการกำหนดค่าของคุณ โปรดดูที่การแก้ไขปัญหา

ใบอนุญาต

อาปาเช่ เวอร์ชั่น 2.0

ดูใบอนุญาต

ข้อสงวนสิทธิ์

นี่ไม่ใช่ผลิตภัณฑ์อย่างเป็นทางการของ Google