Proof of concept for release-please in biocommons.seqrepo

[holtgrewe]

release-please is a useful tool for automating release and changelog generation.

Example Projects

• https://github.com/googleapis/python-storage
• https://github.com/snakemake/snakemake

Prerequisites / Requirements

These things have to be

• Commit messages must follow conventional commits. E.g., they should start with fix: for fixes, feat: for new features, ci: for CI changes, build: for build system changes, docs: for documentation.
• Commits must be limited to squash commits.
• Tickets are linked to in parentheses after the ticket, e.g., ci: introducing release-please (#123).

Needed Changes

• document conventions appropriately, maybe in a .github/pull_request_template.md PR template (cf snakemake's).
• add a CHANGELOG.md file
• protect main branch to require a PR
• (version update in setup.py not necessary as setuptools_scm is used)
• add a .github/workflows/conventional-prs.yml to enforce conventional commit PRs, (cf. snakemake's)
• add a .github/workflows/release-please.yml to create Git tags, create GitHub releases, and publish to pypi (cf. snakemake's)
• register PYPI_TOKEN in the project to make releases to PyPi work

Release Please Workflow

• merged PRs will lead to conventional commit messages as enforced by the conventional-commits workflow
• release-please is triggered on each merge to main and will create and update a PR that updates the changelog (could also update the version in a setup.py file etc.) snakemake example
• you will get a preview of the next version, a fix will bump the patch version, a feat will bump the minor version, any breaking change, e.g., fix!, or feat! will bump the major version
• you can enforce a certain version with a Release-As: major.minor.patch "footer" in the commit message
• once the person doing the releases is happy then they merge the PR
• release-please recognizes the merge to the main tag and will
  • create a tag
  • create a GitHub release with the changelog on the github page
  • build the package and push it to PyPi if the PYPI_TOKEN has been set
• on the next merged PR that contains a "releasable" (I believe ci/build are considered not releasable by default while patch/fix does), a new release-please PR is created
• release-please will maintain the PR with changes

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.