table of contents
| PYTHON-SEMANTIC-RELEASE(1) | python-semantic-release | PYTHON-SEMANTIC-RELEASE(1) |
NAME¶
python-semantic-release - python-semantic-release Documentation
Python Semantic Release (PSR) provides an automated release mechanism determined by SemVer and Commit Message Conventions for your Git projects.
The purpose of this project is to detect what the next version of the project should be from parsing the latest commit messages. If the commit messages describe changes that would require a major, minor or patch version bump, PSR will automatically bump the version number accordingly. PSR, however, does not stop there but will help automate the whole release process. It will update the project code and distribution artifact, upload the artifact and post changelogs to a remotely hosted Version Control System (VCS).
The tool is designed to run inside of a CI/CD pipeline service, but it can also be run locally.
This project was originally inspired by the semantic-release project for JavaScript by Stephan Bönnemann, but the codebases have significantly deviated since then, as PSR as driven towards the goal of providing flexible changelogs and simple initial setup.
INSTALLATION¶
python3 -m pip install python-semantic-release semantic-release --help
Python Semantic Release is also available from conda-forge or as a GitHub Action.
Read more about the setup and configuration in our Getting Started Guide.
DOCUMENTATION CONTENTS¶
CHANGELOG¶
v10.4.1 (2025-09-13)¶
🪲 Bug Fixes¶
- •
- cmd-version: Fix error where --no-tag is not respected, closes #1304 (PR#1329, b090fa2)
📖 Documentation¶
- CHANGELOG: Update hyperlink in v10.4.0's additional info paragraph (PR#1323, 98ef722)
- getting-started-guide: Remove notice about lack of monorepo support, closes #1326 (PR#1327, 3f21f3f)
- github-actions: Fix recommended upstream detection script's upstream name parsing (PR#1328, ccc91c0)
v10.4.0 (2025-09-08)¶
✨ Features¶
- config: Add conventional-monorepo as valid commit_parser type (PR#1143, e18f866)
- parser: Add new conventional-commits standard parser for monorepos, closes #614 (PR#1143, e18f866)
📖 Documentation¶
- Add configuration guide for monorepo use with PSR (PR#1143, e18f866)
- commit-parsers: Introduce conventional commit monorepo parser options & features (PR#1143, e18f866)
- configuration: Update commit_parser option with new conventional-monorepo value (PR#1143, e18f866)
💡 Additional Release Information¶
- •
- config: This release introduces a new built-in parser type that can be utilized for monorepo projects. The type value is conventional-monorepo and when specified it will apply the conventional commit parser to a monorepo environment. This parser has specialized options to help handle monorepo projects as well. For more information, please refer to the Monorepo Docs.
v10.3.2 (2025-09-06)¶
🪲 Bug Fixes¶
- •
- cmd-version: Prevent errors when PSR is executed in non-GitHub CI environments, closes #1315 (PR#1322, 4df4be4)
⚡ Performance Improvements¶
- •
- cmd-version: Re-order operations for faster parsing in version determination (PR#1310, 63e435b)
📖 Documentation¶
- •
- uv-integration: Add --no-changelog to build step to increase job speed (PR#1316, e1aece1)
💡 Additional Release Information¶
- •
- cmd-version: Unfortunately, PSR introduced a bug in 10.3.0 when attempting to provide more CI outputs for GitHub Actions. It required our GitHub client interface to be loaded and even if it was not using GitHub CI to be run. This caused errors in Gitea and likely GitLab/Bitbucket environments. This change prevents that from happening but if any users pipelines were intentionally presenting the environment variable "GITHUB_OUTPUT" to enable action output to enable passing along internal outputs of PSR then their hack will no longer work after this change.
v10.3.1 (2025-08-06)¶
🪲 Bug Fixes¶
- •
- github-actions: Refactor the action output error checking for non-release executions, closes #1307 (PR#1308, 5385724)
📖 Documentation¶
- •
- github-actions: Adjust docs for direct links to action example workflows, closes #1303 (PR#1309, 8efebe2)
v10.3.0 (2025-08-04)¶
✨ Features¶
- github-actions: Add commit_sha as a GitHub Actions output value, closes #717 (PR#1289, 39b647b)
- github-actions: Add previous_version as a GitHub Actions output value (PR#1302, c0197b7)
- github-actions: Add release_notes as a GitHub Actions output value (PR#1300, a3fd23c)
- github-actions: Add release link as a GitHub Actions output value (PR#1301, 888aea1)
🪲 Bug Fixes¶
- github-actions: Fix variable output newlines (PR#1300, a3fd23c)
- util: Fixes no-op log output when commit message contains square-brackets, closes #1251 (PR#1287, f25883f)
📖 Documentation¶
- getting-started: Fixes changelog.exclude_commit_patterns example in startup guide, closes #1291 (PR#1292, 2ce2e94)
- github-actions: Add description of commit_sha GitHub Action output in docs (PR#1289, 39b647b)
- github-actions: Add description of previous_release GitHub Action output (PR#1302, c0197b7)
- github-actions: Add description of release_notes GitHub Action output (PR#1300, a3fd23c)
- github-actions: Add description of release link GitHub Action output (PR#1301, 888aea1)
- README: Update broken links to match re-located destinations (PR#1285, f4ec792)
v10.2.0 (2025-06-29)¶
✨ Features¶
- •
- cmd-version: Adds PACKAGE_NAME value into build command environment (db9bc13)
📖 Documentation¶
- configuration: Update build command environment definition to include PACKAGE_NAME variable (4aa3805)
- uv-integration: Fix configuration guide for uv usage to ensure lock file update (5390145)
v10.1.0 (2025-06-12)¶
✨ Features¶
- •
- cmd-version: Always stage version stamped files & changelog even with --no-commit, closes #1211 (PR#1214, de62334)
📖 Documentation¶
- cmd-version: Improve command description & include common uses (PR#1214, de62334)
- configuration-guide: Add how-to guide for uv integration (PR#1214, de62334)
- github-actions: Clarify with examples of the root_options v10 migration change (PR#1271, fbb63ec)
⚙️ Build System¶
- •
- deps: Expand python-gitlab dependency to include v6.0.0 (PR#1273, 99fc9cc)
v10.0.2 (2025-05-26)¶
🪲 Bug Fixes¶
- •
- github-actions: Add filesystem UID/GID fixer after action workspace modification (PR#1262, 93e23c8)
v10.0.1 (2025-05-25)¶
🪲 Bug Fixes¶
- •
- github-actions: Bump the github-actions dependency to v10.0.0 (PR#1255, 2803676)
v10.0.0 (2025-05-25)¶
✨ Features¶
- cmd-version: Enable version_variables version stamp of vars with double-equals (PR#1244, 080e4bc)
- parser-conventional: Set parser to evaluate all squashed commits by default (6fcdc99)
- parser-conventional: Set parser to ignore merge commits by default (59bf084)
- parser-emoji: Set parser to evaluate all squashed commits by default (514a922)
- parser-emoji: Set parser to ignore merge commits by default (8a51525)
- parser-scipy: Set parser to evaluate all squashed commits by default (634fffe)
- parser-scipy: Set parser to ignore merge commits by default (d4f128e)
🪲 Bug Fixes¶
- changelog-md: Change to 1-line descriptions in markdown template, closes #733 (e7ac155)
- changelog-rst: Change to 1-line descriptions in the default ReStructuredText template, closes #733 (731466f)
- cli: Adjust verbosity parameter to enable silly-level logging (bd3e7bf)
- github-action: Resolve command injection vulnerability in action script (fb3da27)
- parser-conventional: Remove breaking change footer messages from commit descriptions (b271cbb)
- parser-conventional: Remove issue footer messages from commit descriptions (b1bb0e5)
- parser-conventional: Remove PR/MR references from commit subject line (eed63fa)
- parser-conventional: Remove release notice footer messages from commit descriptions (7e8dc13)
- parser-emoji: Remove issue footer messages from commit descriptions (b757603)
- parser-emoji: Remove PR/MR references from commit subject line (16465f1)
- parser-emoji: Remove release notice footer messages from commit descriptions (b6307cb)
- parser-scipy: Remove issue footer messages from commit descriptions (3cfee76)
- parser-scipy: Remove PR/MR references from commit subject line (da4140f)
- parser-scipy: Remove release notice footer messages from commit descriptions (58308e3)
📖 Documentation¶
- Refactor documentation page navigation (4e52f4b)
- algorithm: Remove out-of-date algorithm description (6cd0fbe)
- commit-parsing: Define limitation of revert commits with the scipy parser (5310d0c)
- configuration: Change default value for allow_zero_version in the description (203d29d)
- configuration: Change the default for the base changelog's mask_initial_release value (5fb02ab)
- configuration: Change the default value for changelog.mode in the setting description (0bed906)
- configuration: Update version_variables section to include double-equals operand support (PR#1244, 080e4bc)
- contributing: Refactor contributing & contributors layout (8bed5bc)
- github-actions: Add reference to manual release workflow example (6aad7f1)
- github-actions: Change recommended workflow to separate release from deploy (67b2ae0)
- github-actions: Update python-semantic-release/publish-action parameter notes (c4d45ec)
- github-actions: Update PSR action parameter documentation (a082896)
- upgrading: Re-locate version upgrade guides into Upgrading PSR (a5f5e04)
- upgrading-v10: Added migration guide for v9 to v10 (4ea92ec)
⚙️ Build System¶
- •
- deps: Prevent update to click@8.2.0 (PR#1245, 4aa6a6e)
♻️ Refactoring¶
- config: Change allow_zero_version default to false (c6b6eab)
- config: Change changelog.default_templates.mask_initial_release default to true (0e114c3)
- config: Change changelog.mode default to update (7d39e76)
💥 Breaking Changes¶
SEE ALSO:
- changelog-md: The default Markdown changelog template and release notes template will no longer print out the entire commit message contents, instead, it will only print the commit subject line. This comes to meet the high demand of better formatted changelogs and requests for subject line only. Originally, it was a decision to not hide commit subjects that were included in the commit body via the git merge --squash command and PSR did not have another alternative. At this point, all the built-in parsers have the ability to parse squashed commits and separate them out into their own entry on the changelog. Therefore, the default template no longer needs to write out the full commit body. See the commit parser options if you want to enable/disable parsing squash commits.
- changelog-rst: The default ReStructured changelog template will no longer print out the entire commit message contents, instead, it will only print the commit subject line. This comes to meet the high demand of better formatted changelogs and requests for subject line only. Originally, it was a decision to not hide commit subjects that were included in the commit body via the git merge --squash command and PSR did not have another alternative. At this point, all the built-in parsers have the ability to parse squashed commits and separate them out into their own entry on the changelog. Therefore, the default template no longer needs to write out the full commit body. See the commit parser options if you want to enable/disable parsing squash commits.
- config: This release switches the allow_zero_version default to false. This change is to encourage less 0.x releases as the default but rather allow the experienced developer to choose when 0.x is appropriate. There are way too many projects in the ecosystems that never leave 0.x and that is problematic for the industry tools that help auto-update based on SemVer. We should strive for publishing usable tools and maintaining good forethought for when compatibility must break. If your configuration already sets the allow_zero_version value, this change will have no effect on your project. If you want to use 0.x versions, from the start then change allow_zero_version to true in your configuration.
- config: This release switches the changelog.default_templates.mask_initial_release default to true. This change is intended to toggle better recommended outputs of the default changelog. Conceptually, the very first release is hard to describe--one can only provide new features as nothing exists yet for the end user. No changelog should be written as there is no start point to compare the "changes" to. The recommendation instead is to only list a simple message as Initial Release. This is now the default for PSR when providing the very first release (no pre-existing tags) in the changelog and release notes. If your configuration already sets the changelog.default_templates.mask_initial_release value, then this change will have no effect on your project. If you do NOT want to mask the first release information, then set changelog.default_templates.mask_initial_release to false in your configuration.
- config: This release switches the changelog.mode default to update. In this mode, if a changelog exists, PSR will update the changelog IF AND ONLY IF the configured insertion flag exists in the changelog. The Changelog output will remain unchanged if no insertion flag exists. The insertion flag may be configured with the changelog.insertion_flag setting. When upgrading to v10, you must add the insertion flag manually or you can just delete the changelog file and run PSR's changelog generation and it will rebuild the changelog (similar to init mode) but it will add the insertion flag. If your configuration already sets the changelog.mode value, then this change will have no effect on your project. If you would rather the changelog be generated from scratch every release, than set the changelog.mode value to init in your configuration.
- github-action: The root_options action input parameter has been removed because it created a command injection vulnerability for arbitrary code to execute within the container context of the GitHub action if a command injection code was provided as part of the root_options parameter string. To eliminate the vulnerability, each relevant option that can be provided to semantic-release has been individually added as its own parameter and will be processed individually to prevent command injection. Please review our Github Actions Configuration page to review the newly available configuration options that replace the root_options parameter.
- parser-conventional: Any breaking change footer messages that the conventional commit parser detects will now be removed from the commit.descriptions[] list but maintained in and only in the commit.breaking_descriptions[] list. Previously, the descriptions included all text from the commit message but that was redundant as the default changelog now handles breaking change footers in its own section.
- parser-conventional, parser-emoji, parser-scipy: Any issue resolution footers that the parser detects will now be removed from the commit.descriptions[] list. Previously, the descriptions included all text from the commit message but now that the parser pulls out the issue numbers the numbers will be included in the commit.linked_issues tuple for user extraction in any changelog generation.
- parser-conventional, parser-emoji, parser-scipy: Any release notice footer messages that the commit parser detects will now be removed from the commit.descriptions[] list but maintained in and only in the commit.notices[] list. Previously, the descriptions included all text from the commit message but that was redundant as the default changelog now handles release notice footers in its own section.
- parser-conventional, parser-emoji, parser-scipy: Generally, a pull request or merge request number reference is included in the subject line at the end within parentheses on some common VCS's like GitHub. PSR now looks for this reference and extracts it into the commit.linked_merge_request and the commit.linked_pull_request attributes of a commit object. Since this is now pulled out individually, it is cleaner to remove this from the first line of the commit.descriptions list (ie. the subject line) so that changelog macros do not have to replace the text but instead only append a PR/MR link to the end of the line. The reference does maintain the PR/MR prefix indicator (# or !).
- parser-conventional, parser-emoji, parser-scipy: The configuration setting commit_parser_options.ignore_merge_commits is now set to true by default. The feature to ignore squash commits was introduced in v9.18.0 and was originally set to false to prevent unexpected results on a non-breaking update. The ignore merge commits feature prevents additional unnecessary processing on a commit message that likely will not match a commit message syntax. Most merge commits are syntactically pre-defined by Git or Remote Version Control System (ex. GitHub, etc.) and do not follow a commit convention (nor should they). The larger issue with merge commits is that they ultimately are a full copy of all the changes that were previously created and committed. The merge commit itself ensures that the previous commit tree is maintained in history, therefore the commit message always exists. If merge commits are parsed, it generally creates duplicate messages that will end up in your changelog, which is less than desired in most cases. If you have previously used the changelog.exclude_commit_patterns functionality to ignore merge commit messages then you will want this setting set to true to improve parsing speed. You can also now remove the merge commit exclude pattern from the list as well to improve parsing speed. If this functionality is not desired, you will need to update your configuration to change the new setting to false.
- parser-conventional, parser-emoji, parser-scipy: The configuration setting commit_parser_options.parse_squash_commits is now set to true by default. The feature to parse squash commits was introduced in v9.17.0 and was originally set to false to prevent unexpected results on a non-breaking update. The parse squash commits feature attempts to find additional commits of the same commit type within the body of a single commit message. When squash commits are found, Python Semantic Release will separate out each commit into its own artificial commit object and parse them individually. This potentially can change the resulting version bump if a larger bump was detected within the squashed components. It also allows for the changelog and release notes to separately order and display each commit as originally written. If this is not desired, you will need to update your configuration to change the new setting to false.
v9.21.1 (2025-05-05)¶
🪲 Bug Fixes¶
- •
- changelog-filters: Fixes url resolution when prefix & path share letters, closes #1204 (PR#1239, f61f8a3)
📖 Documentation¶
- •
- github-actions: Expound on monorepo example to include publishing actions (PR#1229, 550e85f)
⚙️ Build System¶
- deps: Bump rich dependency from 13.0 to 14.0 (PR#1224, 691536e)
- deps: Expand python-gitlab dependency to include v5.0.0 (PR#1228, a0cd1be)
v9.21.0 (2025-02-23)¶
✨ Features¶
- •
- Add package name variant, python-semantic-release, project script, closes #1195 (PR#1199, 1ac97bc)
📖 Documentation¶
- •
- github-actions: Update example workflow to handle rapid merges (PR#1200, 1a4116a)
v9.20.0 (2025-02-17)¶
✨ Features¶
- cmd-version: Enable stamping of tag formatted versions into files, closes #846 (PR#1190, 8906d8e)
- cmd-version: Extend version_variables to stamp versions with @ symbol separator, closes #1156 (PR#1185, 23f69b6)
📖 Documentation¶
- configuration: Add usage information for tag format version stamping (PR#1190, 8906d8e)
- configuration: Clarify version_variables config description & @ separator usage (PR#1185, 23f69b6)
⚙️ Build System¶
- •
- deps: Add deprecated~=1.2 for deprecation notices & sphinx documentation (PR#1190, 8906d8e)
v9.19.1 (2025-02-11)¶
🪲 Bug Fixes¶
- changelog: Standardize heading format for across all version sections (PR#1182, 81f9e80)
- changelog-md: Standardize heading format for extra release information (PR#1182, 81f9e80)
- changelog-rst: Standardize heading format for extra release information (PR#1182, 81f9e80)
- config: Handle invalid commit_parser type gracefully (PR#1180, 903c8ba)
- release-notes: Standardize heading format for extra release information (PR#1182, 81f9e80)
📖 Documentation¶
- Fix spelling errors & inaccurate descriptions (55d4a05)
- automatic-releases: Declutter the table of contents for automatic release guides (e8343ee)
- commit-parsing: Update reference to section name of additional release info (PR#1182, 81f9e80)
v9.19.0 (2025-02-10)¶
✨ Features¶
- •
- parser-conventional: Add official conventional-commits parser (PR#1177, 27ddf84)
📖 Documentation¶
- •
- Update references to Angular parser to Conventional Commit Parser (PR#1177, 27ddf84)
💡 Additional Release Information¶
- •
- parser-conventional: The 'angular' commit parser has been renamed to 'conventional' to match the official conventional-commits standard for which the 'angular' parser has evolved into. Please update your configurations to specify 'conventional' as the 'commit_parser' value in place of 'angular'. The 'angular' type will be removed in v11.
v9.18.1 (2025-02-08)¶
🪲 Bug Fixes¶
- •
- config: Refactors default token resolution to prevent pre-mature insecure URL error, closes #1074, #1169 (PR#1173, 37db258)
v9.18.0 (2025-02-06)¶
✨ Features¶
- Add create_release_url & format_w_official_vcs_name filters (PR#1161, f853cf0)
- changelog: Add create_pypi_url filter to jinja template render context (PR#1160, 45d49c3)
- changelog: Add additional release info to changeling from commit NOTICE's (PR#1166, 834ce32)
- changelog-md: Add additional release info section to default markdown template, closes #223 (PR#1166, 834ce32)
- changelog-rst: Add additional release info section to default ReStructuredText template, closes #223 (PR#1166, 834ce32)
- commit-parser: Enable parsers to identify additional release notices from commit msgs (PR#1166, 834ce32)
- parser-angular: Add a ignore_merge_commits option to discard parsing merge commits (PR#1164, 463e43b)
- parser-angular: Add functionality to parse out NOTICE: prefixed statements in commits, closes #223 (PR#1166, 834ce32)
- parser-emoji: Add a ignore_merge_commits option to discard parsing merge commits (PR#1164, 463e43b)
- parser-emoji: Add functionality to parse out NOTICE: prefixed statements in commits, closes #223 (PR#1166, 834ce32)
- parsers: Add option ignore_merge_commits to discard parsing merge commits (PR#1164, 463e43b)
- release-notes: Add license information to default release notes template, closes #228 (PR#1167, 41172c1)
- vcs-bitbucket: Add format_w_official_vcs_name filter function (PR#1161, f853cf0)
- vcs-gitea: Add create_release_url & format_w_official_vcs_name filter functions (PR#1161, f853cf0)
- vcs-github: Add create_release_url & format_w_official_vcs_name filter functions (PR#1161, f853cf0)
- vcs-gitlab: Add create_release_url & format_w_official_vcs_name filter functions (PR#1161, f853cf0)
🪲 Bug Fixes¶
- Refactor parsing compatibility function to support older custom parsers (PR#1165, cf340c5)
- changelog: Fix parsing compatibility w/ custom parsers, closes #1162 (PR#1165, cf340c5)
- changelog-templates: Adjust default templates to avoid empty version sections (PR#1164, 463e43b)
- parser-angular: Adjust parser to prevent empty message extractions (PR#1166, 834ce32)
- parser-emoji: Adjust parser to prevent empty message extractions (PR#1166, 834ce32)
- version: Fix parsing compatibility w/ custom parsers, closes #1162 (PR#1165, cf340c5)
📖 Documentation¶
- changelog: Add formatted changelog into hosted documentation (PR#1155, 2f18a6d)
- changelog-templates: Add description for new create_pypi_url filter function (PR#1160, 45d49c3)
- changelog-templates: Add details about license specification in the release notes (PR#1167, 41172c1)
- changelog-templates: Define create_release_url & format_w_official_vcs_name filters (PR#1161, f853cf0)
- changelog-templates: Document special separate sections of commit descriptions (ebb4c67)
- commit-parsing: Document new release notice footer detection feature of built-in parsers (cd14e92)
v9.17.0 (2025-01-26)¶
✨ Features¶
- changelog: Add sort_numerically filter function to template environment (PR#1146, 7792388)
- changelog: Parse squashed commits individually (PR#1112, cf785ca)
- config: Extend support of remote urls aliased using git insteadOf configurations, closes #1150 (PR#1151, 4045037)
- parsers: Parse squashed commits individually (PR#1112, cf785ca)
- parser-angular: Apply PR/MR numbers to all parsed commits from a squash merge (PR#1112, cf785ca)
- parser-angular: Upgrade angular parser to parse squashed commits individually, closes #1085 (PR#1112, cf785ca)
- parser-emoji: Add functionality to interpret scopes from gitmoji commit messages (PR#1112, cf785ca)
- parser-emoji: Upgrade emoji parser to parse squashed commits individually (PR#1112, cf785ca)
- version: Parse squashed commits individually (PR#1112, cf785ca)
🪲 Bug Fixes¶
- •
- github-action: Disable writing python bytecode in action execution (PR#1152, 315ae21)
⚡ Performance Improvements¶
- •
- logging: Remove irrelevant debug logging statements (PR#1147, f1ef4ec)
📖 Documentation¶
- changelog-templates: Add description for new sort_numerically filter function (PR#1146, 7792388)
- commit-parsing: Add description for squash commit evaluation option of default parsers (PR#1112, cf785ca)
- configuration: Update the commit_parser_options setting description (PR#1112, cf785ca)
v9.16.1 (2025-01-12)¶
🪲 Bug Fixes¶
- •
- parser-custom: Handle relative parent directory paths to module file better (PR#1142, c4056fc)
📖 Documentation¶
- •
- github-actions: Update PSR versions in github workflow examples (PR#1140, 9bdd626)
v9.16.0 (2025-01-12)¶
✨ Features¶
- •
- config: Expand dynamic parser import to handle a filepath to module (PR#1135, 0418fd8)
🪲 Bug Fixes¶
- changelog: Fixes PSR release commit exclusions for customized commit messages (PR#1139, f9a2078)
- cmd-version: Fixes --print-tag result to match configured tag format (PR#1134, a990aa7)
- cmd-version: Fixes tag format on default version when force bump for initial release, closes #1137 (PR#1138, 007fd00)
- config-changelog: Validate changelog.exclude_commit_patterns on config load (PR#1139, f9a2078)
📖 Documentation¶
- commit-parsing: Add the new custom parser import spec description for direct path imports, closes #687 (PR#1135, 0418fd8)
- configuration: Adjust commit_parser option definition for direct path imports (PR#1135, 0418fd8)
v9.15.2 (2024-12-16)¶
🪲 Bug Fixes¶
- changelog: Ensures user rendered files are trimmed to end with a single newline (PR#1118, 6dfbbb0)
- cli: Add error message of how to gather full error output (PR#1116, ba85532)
- cmd-version: Enable maintenance prereleases (PR#864, b88108e)
- cmd-version: Fix handling of multiple prerelease token variants & git flow merges (PR#1120, 8784b9a)
- cmd-version: Fix version determination algorithm to capture commits across merged branches (PR#1120, 8784b9a)
- cmd-version: Forces tag timestamp to be same time as release commit (PR#1117, 7898b11)
- cmd-version: Handle multiple prerelease token variants properly, closes #789 (PR#1120, 8784b9a)
- config: Ensure default config loads on network mounted windows environments, closes #1123 (PR#1124, a64cbc9)
- version: Remove some excessive log msgs from debug to silly level (PR#1120, 8784b9a)
- version-bump: Increment based on current commit's history only, closes #861 (PR#864, b88108e)
⚡ Performance Improvements¶
- •
- cmd-version: Refactor version determination algorithm for accuracy & speed (PR#1120, 8784b9a)
v9.15.1 (2024-12-03)¶
🪲 Bug Fixes¶
- changelog-md: Fix commit sort of breaking descriptions section (75b342e)
- parser-angular: Ensure issues are sorted by numeric value rather than text sorted (3858add)
- parser-emoji: Ensure issues are sorted by numeric value rather than text sorted (7b8d2d9)
v9.15.0 (2024-12-02)¶
✨ Features¶
- changelog-md: Add a breaking changes section to default Markdown template, closes #244 (PR#1110, 4fde30e)
- changelog-md: Alphabetize breaking change descriptions in markdown changelog template (PR#1110, 4fde30e)
- changelog-md: Alphabetize commit summaries & scopes in markdown changelog template (PR#1111, 8327068)
- changelog-rst: Add a breaking changes section to default reStructuredText template, closes #244 (PR#1110, 4fde30e)
- changelog-rst: Alphabetize breaking change descriptions in ReStructuredText template (PR#1110, 4fde30e)
- changelog-rst: Alphabetize commit summaries & scopes in ReStructuredText template (PR#1111, 8327068)
- commit-parser: Enable parsers to flag commit to be ignored for changelog, closes #778 (PR#1108, 0cc668c)
- default-changelog: Add a separate formatted breaking changes section, closes #244 (PR#1110, 4fde30e)
- default-changelog: Alphabetize commit summaries & scopes in change sections (PR#1111, 8327068)
- parsers: Add other_allowed_tags option for commit parser options (PR#1109, f90b8dc)
- parsers: Enable parsers to identify linked issues on a commit (PR#1109, f90b8dc)
- parser-angular: Automatically parse angular issue footers from commit messages (PR#1109, f90b8dc)
- parser-custom: Enable custom parsers to identify linked issues on a commit (PR#1109, f90b8dc)
- parser-emoji: Parse issue reference footers from commit messages (PR#1109, f90b8dc)
- release-notes: Add tag comparison link to release notes when supported (PR#1107, 9073344)
🪲 Bug Fixes¶
- cmd-version: Ensure release utilizes a timezone aware datetime (ca817ed)
- default-changelog: Alphabetically sort commit descriptions in version type sections (bdaaf5a)
- util: Prevent git footers from being collapsed during parse (PR#1109, f90b8dc)
📖 Documentation¶
- api-parsers: Add option documentation to parser options (PR#1109, f90b8dc)
- changelog-templates: Update examples using new commit.linked_issues attribute (PR#1109, f90b8dc)
- commit-parsing: Improve & expand commit parsing w/ parser descriptions (PR#1109, f90b8dc)
v9.14.0 (2024-11-11)¶
✨ Features¶
- changelog: Add md to rst conversion for markdown inline links (cb2af1f)
- changelog: Define first release w/o change descriptions for default MD template (fa89dec)
- changelog: Define first release w/o change descriptions for default RST template (e30c94b)
- changelog: Prefix scopes on commit descriptions in default template (PR#1093, 560fd2c)
- changelog-md: Add markdown inline link format macro (c6d8211)
- changelog-md: Prefix scopes on commit descriptions in Markdown changelog template (PR#1093, 560fd2c)
- changelog-rst: Prefix scopes on commit descriptions in ReStructuredText template (PR#1093, 560fd2c)
- configuration: Add changelog.default_templates.mask_initial_release option (595a70b)
- context: Add mask_initial_release setting to changelog context (6f2ee39)
- release-notes: Define first release w/o change descriptions in default template (83167a3)
🪲 Bug Fixes¶
- •
- release-notes: Override default word-wrap to non-wrap for in default template (99ab99b)
📖 Documentation¶
- changelog-templates: Document new mask_initial_release changelog context variable (f294957)
- configuration: Document new mask_initial_release option usage & effect (3cabcdc)
- homepage: Fix reference to new ci workflow for test status badge (6760069)
v9.13.0 (2024-11-10)¶
✨ Features¶
- changelog: Add PR/MR url linking to default Markdown changelog, closes #924, #953 (cd8d131)
- changelog: Add PR/MR url linking to default reStructuredText template, closes #924, #953 (5f018d6)
- parsed-commit: Add linked merge requests list to the ParsedCommit object (9a91062)
- parser-angular: Automatically parse PR/MR numbers from subject lines in commits (2ac798f)
- parser-emoji: Automatically parse PR/MR numbers from subject lines in commits (bca9909)
- parser-scipy: Automatically parse PR/MR numbers from subject lines in commits (2b3f738)
🪲 Bug Fixes¶
- changelog-rst: Ignore unknown parsed commit types in default RST changelog (77609b1)
- parser-angular: Drop the breaking category but still maintain a major level bump (f1ffa54)
- parsers: Improve reliability of descriptions after reverse word-wrap (436374b)
⚡ Performance Improvements¶
- parser-angular: Simplify commit parsing type pre-calculation (a86a28c)
- parser-emoji: Increase speed of commit parsing (2c9c468)
- parser-scipy: Increase speed & decrease complexity of commit parsing (2b661ed)
📖 Documentation¶
- changelog-templates: Add linked_merge_request field to examples (d4376bc)
- changelog-templates: Fix api class reference links (7a5bdf2)
- commit-parsing: Add linked_merge_request field to Parsed Commit definition (ca61889)
v9.12.2 (2024-11-07)¶
🪲 Bug Fixes¶
- bitbucket: Fix pull_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
- cli: Gracefully capture all exceptions unless in very verbose debug mode (PR#1088, 13ca44f)
- gitea: Fix issue_url filter to ignore an issue prefix gracefully (PR#1089, 275ec88)
- gitea: Fix pull_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
- github: Fix issue_url filter to ignore an issue prefix gracefully (PR#1089, 275ec88)
- github: Fix pull_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
- gitlab: Fix issue_url filter to ignore an issue prefix gracefully (PR#1089, 275ec88)
- gitlab: Fix merge_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
- hvcs: Add flexibility to issue & MR/PR url jinja filters (PR#1089, 275ec88)
📖 Documentation¶
- •
- changelog-templates: Update descriptions of issue & MR/PR url jinja filters (PR#1089, 275ec88)
v9.12.1 (2024-11-06)¶
🪲 Bug Fixes¶
- changelog: Fix raw-inline pattern replacement in convert_md_to_rst filter (2dc70a6)
- cmd-version: Fix --as-prerelease when no commit change from last full release (PR#1076, 3b7b772)
- release-notes: Add context variable shorthand ctx like docs claim & changelog has (d618d83)
📖 Documentation¶
- •
- contributing: Update local testing instructions (74f03d4)
v9.12.0 (2024-10-18)¶
✨ Features¶
- •
- changelog: Add autofit_text_width filter to template environment (PR#1062, 83e4b86)
🪲 Bug Fixes¶
- changelog: Ignore commit exclusion when a commit causes a version bump (e8f886e)
- parser-angular: Change Fixes commit type heading to Bug Fixes (PR#1064, 09e3a4d)
- parser-emoji: Enable the default bump level option (bc27995)
📖 Documentation¶
- changelog-templates: Add definition & usage of autofit_text_width template filter (PR#1062, 83e4b86)
- commit-parsers: Add deprecation message for the tag parser (af94540)
- configuration: Add deprecation message for the tag parser (a83b7e4)
v9.11.1 (2024-10-15)¶
🪲 Bug Fixes¶
- •
- changelog: Prevent custom template errors when components are in hidden folders (PR#1060, a7614b0)
v9.11.0 (2024-10-12)¶
✨ Features¶
- changelog: Add convert_md_to_rst filter to changelog environment (PR#1055, c2e8831)
- changelog: Add default changelog in re-structured text format, closes #399 (PR#1055, c2e8831)
- changelog: Add default changelog template in reStructuredText format (PR#1055, c2e8831)
- config: Enable default changelog.insertion_flag based on output format (PR#1055, c2e8831)
- config: Enable target changelog filename to trigger RST output format, closes #399 (PR#1055, c2e8831)
🪲 Bug Fixes¶
- •
- changelog: Correct spacing for default markdown template during updates (PR#1055, c2e8831)
📖 Documentation¶
- changelog: Clarify the convert_md_to_rst filter added to the template environment (PR#1055, c2e8831)
- changelog: Increase detail about configuration options of default changelog creation (PR#1055, c2e8831)
- configuration: Update changelog_file with deprecation notice of setting relocation (PR#1055, c2e8831)
- configuration: Update output_format description for reStructuredText support (PR#1055, c2e8831)
- configuration: Update details of insertion_flag's dynamic defaults with rst (PR#1055, c2e8831)
v9.10.1 (2024-10-10)¶
🪲 Bug Fixes¶
- •
- config: Handle branch match regex errors gracefully (PR#1054, 4d12251)
v9.10.0 (2024-10-08)¶
✨ Features¶
- changelog: Add changelog_insertion_flag to changelog template context (PR#1045, c18c245)
- changelog: Add changelog_mode to changelog template context (PR#1045, c18c245)
- changelog: Add prev_changelog_file to changelog template context (PR#1045, c18c245)
- changelog: Add read_file function to changelog template context (PR#1045, c18c245)
- changelog: Add shorthand ctx variable to changelog template env (PR#1045, c18c245)
- changelog: Modify changelog template to support changelog updates, closes #858 (PR#1045, c18c245)
- config: Add changelog.default_templates.output_format config option (PR#1045, c18c245)
- config: Add changelog.insertion_flag as configuration option (PR#1045, c18c245)
- config: Add changelog.mode as configuration option (PR#1045, c18c245)
- github-actions: Add an action build directive to toggle the --skip-build option (PR#1044, 26597e2)
🪲 Bug Fixes¶
- changelog: Adjust angular heading names for readability (PR#1045, c18c245)
- changelog: Ensure changelog templates can handle complex directory includes (PR#1045, c18c245)
- changelog: Only render user templates when files exist (PR#1045, c18c245)
- config: Prevent jinja from autoescaping markdown content by default (PR#1045, c18c245)
📖 Documentation¶
- changelog-templates: Improve detail & describe new changelog.mode="update" (PR#1045, c18c245)
- commands: Update definition of the version commands --skip-build option (PR#1044, 26597e2)
- configuration: Add changelog.mode and changelog.insertion_flag config definitions (PR#1045, c18c245)
- configuration: Define the new changelog.default_templates.output_format option (PR#1045, c18c245)
- configuration: Mark version of configuration setting introduction (PR#1045, c18c245)
- configuration: Standardize all true/false to lowercase ensuring toml-compatibility (PR#1045, c18c245)
- configuration: Update changelog.environment.autoescape default to false to match code (PR#1045, c18c245)
- github-actions: Add description of the build input directive (PR#1044, 26597e2)
- github-actions: Update primary example with workflow sha controlled pipeline (14f04df)
- homepage: Update custom changelog reference (PR#1045, c18c245)
v9.9.0 (2024-09-28)¶
✨ Features¶
- •
- github-actions: Add is_prerelease output to the version action (PR#1038, 6a5d35d)
📖 Documentation¶
- automatic-releases: Drop extraneous github push configuration (PR#1011, 2135c68)
- github-actions: Add configuration & description of publish action (PR#1011, 2135c68)
- github-actions: Add description of new is_prerelease output for version action (PR#1038, 6a5d35d)
- github-actions: Clarify & consolidate GitHub Actions usage docs, closes #907 (PR#1011, 2135c68)
- github-actions: Expand descriptions & clarity of actions configs (PR#1011, 2135c68)
- github-actions: Revert removal of namespace prefix from examples (PR#1011, 2135c68)
- homepage: Remove link to old github config & update token scope config (PR#1011, 2135c68)
v9.8.9 (2024-09-27)¶
🪲 Bug Fixes¶
- version-cmd: Ensure version_variables do not match partial variable names (PR#1028, 156915c)
- version-cmd: Improve version_variables flexibility w/ quotes (ie. json, yaml, etc) (PR#1028, 156915c)
- version-cmd: Increase version_variable flexibility with quotations (ie. json, yaml, etc), closes #601, #706, #962, #1026 (PR#1028, 156915c)
📖 Documentation¶
- Update docstrings to resolve sphinx failures, closes #1029 (PR#1030, d84efc7)
- configuration: Add clarity to version_variables usage & limitations (PR#1028, 156915c)
- homepage: Re-structure homepage to be separate from project readme (PR#1032, 2307ed2)
- README: Simplify README to point at official docs (PR#1032, 2307ed2)
v9.8.8 (2024-09-01)¶
🪲 Bug Fixes¶
- •
- config: Fix path traversal detection for windows compatibility, closes #994 (PR#1014, 16e6daa)
📖 Documentation¶
- configuration: Update build_command env table for windows to use all capital vars (0e8451c)
- github-actions: Update version in examples to latest version (3c894ea)
v9.8.7 (2024-08-20)¶
🪲 Bug Fixes¶
- Provide context.history global in release notes templates (PR#1005, 5bd91b4)
- release-notes: Fix noop-changelog to print raw release notes (PR#1005, 5bd91b4)
- release-notes: Provide context.history global in release note templates, closes #984 (PR#1005, 5bd91b4)
📖 Documentation¶
- Use pinned version for GHA examples (PR#1004, 5fdf761)
- changelog: Clarify description of the default changelog generation process (399fa65)
- configuration: Clarify changelog_file vs template_dir option usage, closes #983 (a7199c8)
- configuration: Fix build_command_env table rendering (PR#996, a5eff0b)
- github-actions: Adjust formatting & version warning in code snippets (PR#1004, 5fdf761)
- github-actions: Use pinned version for GHA examples, closes #1003 (PR#1004, 5fdf761)
v9.8.6 (2024-07-20)¶
🪲 Bug Fixes¶
- •
- version-cmd: Resolve build command execution in powershell (PR#980, 32c8e70)
📖 Documentation¶
- •
- configuration: Correct GHA parameter name for commit email (PR#981, ce9ffdb)
v9.8.5 (2024-07-06)¶
🪲 Bug Fixes¶
- Enable --print-last-released* when in detached head or non-release branch (PR#926, 782c0a6)
- changelog: Resolve commit ordering issue when dates are similar (PR#972, bfda159)
- version-cmd: Drop branch restriction for --print-last-released* opts, closes #900 (PR#926, 782c0a6)
⚡ Performance Improvements¶
- Improve git history processing for changelog generation (PR#972, bfda159)
- changelog: Improve git history parser changelog generation (PR#972, bfda159)
v9.8.4 (2024-07-04)¶
🪲 Bug Fixes¶
- changelog-cmd: Remove usage strings when error occurred, closes #810 (348a51d)
- changelog-cmd: Render default changelog when user template directory exist but is empty (bded8de)
- config: Prevent path traversal manipulation of target changelog location (43e35d0)
- config: Prevent path traversal manipulation of target changelog location (3eb3dba)
- publish-cmd: Prevent error when provided tag does not exist locally (16afbbb)
- publish-cmd: Remove usage strings when error occurred, closes #810 (afbb187)
- version-cmd: Remove usage strings when error occurred, closes #810 (a7c17c7)
v9.8.3 (2024-06-18)¶
🪲 Bug Fixes¶
- •
- parser: Strip DOS carriage-returns in commits, closes #955 (PR#956, 0b005df)
v9.8.2 (2024-06-17)¶
🪲 Bug Fixes¶
- •
- templates: Suppress extra newlines in default changelog (PR#954, 7b0079b)
v9.8.1 (2024-06-05)¶
🪲 Bug Fixes¶
- Improve build cmd env on windows (PR#942, d911fae)
- version-cmd: Pass windows specific env vars to build cmd when on windows (PR#942, d911fae)
📖 Documentation¶
- •
- configuration: Define windows specific env vars for build cmd (PR#942, d911fae)
v9.8.0 (2024-05-27)¶
✨ Features¶
- Extend gitlab to edit a previous release if exists (PR#934, 23e02b9)
- gha: Configure ssh signed tags in GitHub Action, closes #936 (PR#937, dfb76b9)
- hvcs-gitlab: Enable gitlab to edit a previous release if found (PR#934, 23e02b9)
- version-cmd: Add toggle of --no-verify option to git commit (PR#927, 1de6f78)
🪲 Bug Fixes¶
- gitlab: Adjust release name to mirror other hvcs release names (PR#934, 23e02b9)
- hvcs-gitlab: Add tag message to release creation (PR#934, 23e02b9)
📖 Documentation¶
- configuration: Add no_git_verify description to the configuration page (PR#927, 1de6f78)
- migration-v8: Update version references in migration instructions (PR#938, d6ba16a)
v9.7.3 (2024-05-15)¶
🪲 Bug Fixes¶
- •
- Enabled prerelease-token parameter in github action (PR#929, 1bb26b0)
v9.7.2 (2024-05-13)¶
🪲 Bug Fixes¶
- Enable user configuration of build_command env vars (PR#925, 6b5b271)
- version: Enable user config of build_command env variables, closes #922 (PR#925, 6b5b271)
📖 Documentation¶
- configuration: Clarify TOC & alphabetize configuration descriptions (19add16)
- configuration: Clarify TOC & standardize heading links (3a41995)
- configuration: Document build_command_env configuration option (PR#925, 6b5b271)
- CONTRIBUTING: Update build command definition for developers (PR#921, b573c4d)
v9.7.1 (2024-05-07)¶
🪲 Bug Fixes¶
- •
- gha: Fix missing git_committer_* definition in action, closes #918 (PR#919, ccef9d8)
v9.7.0 (2024-05-06)¶
✨ Features¶
- •
- version-cmd: Pass NEW_VERSION & useful env vars to build command (ee6b246)
🪲 Bug Fixes¶
- gha: Add missing tag option to GitHub Action definition, closes #906 (PR#908, 6b24288)
- gha: Correct use of prerelease option for GitHub Action (PR#914, 85e27b7)
📖 Documentation¶
- configuration: Add description of build command available env variables (c882dc6)
- gha: Update GitHub Actions doc with all available options (PR#914, 85e27b7)
⚙️ Build System¶
- •
- deps: Bump GitHub Action container to use python3.12, closes #801 (PR#914, 85e27b7)
v9.6.0 (2024-04-29)¶
✨ Features¶
- Changelog filters are specialized per vcs type (PR#890, 76ed593)
- changelog: Changelog filters are hvcs focused (PR#890, 76ed593)
- changelog-context: Add flag to jinja env for which hvcs is available (PR#890, 76ed593)
- changelog-gitea: Add issue url filter to changelog context (PR#890, 76ed593)
- changelog-github: Add issue url filter to changelog context (PR#890, 76ed593)
- version-cmd: Add --as-prerelease option to force the next version to be a prerelease, closes #639 (PR#647, 2acb5ac)
🪲 Bug Fixes¶
- Correct version --prerelease use & enable --as-prerelease (PR#647, 2acb5ac)
- github: Correct changelog filter for pull request urls (PR#890, 76ed593)
- parser-custom: Gracefully handle custom parser import errors (67f6038)
- version-cmd: Correct --prerelease use, closes #639 (PR#647, 2acb5ac)
📖 Documentation¶
- changelog-context: Explain new hvcs specific context filters (PR#890, 76ed593)
- commands: Update version command options definition about prereleases (PR#647, 2acb5ac)
v9.5.0 (2024-04-23)¶
✨ Features¶
- Extend support to on-prem GitHub Enterprise Server (PR#896, 4fcb737)
- github: Extend support to on-prem GitHub Enterprise Server, closes #895 (PR#896, 4fcb737)
v9.4.2 (2024-04-14)¶
🪲 Bug Fixes¶
- bitbucket: Allow insecure http connections if configured (PR#886, db13438)
- bitbucket: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
- config: Add flag to allow insecure connections (PR#886, db13438)
- gitea: Allow insecure http connections if configured (PR#886, db13438)
- gitea: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
- github: Allow insecure http connections if configured (PR#886, db13438)
- github: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
- gitlab: Allow insecure http connections if configured (PR#886, db13438)
- gitlab: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
- hvcs: Allow insecure http connections if configured (PR#886, db13438)
- hvcs: Prevent double protocol scheme urls in changelogs (PR#676, 5cfdb24)
- version-cmd: Handle HTTP exceptions more gracefully (PR#886, db13438)
📖 Documentation¶
- •
- configuration: Update remote settings section with missing values, closes #868 (PR#886, db13438)
⚙️ Build System¶
- •
- deps: Update rich requirement from ~=12.5 to ~=13.0, closes #888 (PR#877, 4a22a8c)
v9.4.1 (2024-04-06)¶
🪲 Bug Fixes¶
- gh-actions-output: Fixed trailing newline to match GITHUB_OUTPUT format (PR#885, 2c7b6ec)
- gh-actions-output: Fixed trailing newline to match GITHUB_OUTPUT format, closes #884 (PR#885, 2c7b6ec)
v9.4.0 (2024-03-31)¶
✨ Features¶
- •
- gitea: Derives gitea api domain from base domain when unspecified (PR#675, 2ee3f8a)
v9.3.1 (2024-03-24)¶
🪲 Bug Fixes¶
- algorithm: Handle merge-base errors gracefully, closes #724 (4c998b7)
- cli-version: Change implementation to only push the tag we generated, closes #803 (8a9da4f)
⚡ Performance Improvements¶
- •
- algorithm: Simplify logs & use lookup when searching for commit & tag match (3690b95)
v9.3.0 (2024-03-21)¶
✨ Features¶
- cmd-version: Changelog available to bundle (PR#779, 37fdb28)
- cmd-version: Create changelog prior to build enabling doc bundling (PR#779, 37fdb28)
v9.2.2 (2024-03-19)¶
🪲 Bug Fixes¶
- •
- cli: Enable subcommand help even if config is invalid, closes #840 (91d221a)
v9.2.1 (2024-03-19)¶
🪲 Bug Fixes¶
- •
- parse-git-url: Handle urls with url-safe special characters (27cd93a)
v9.2.0 (2024-03-18)¶
✨ Features¶
- version: Add new version print flags to display the last released version and tag (814240c)
- version-config: Add option to disable 0.x.x versions (dedb3b7)
🪲 Bug Fixes¶
- changelog: Make sure default templates render ending in 1 newline (0b4a45e)
- changelog-generation: Fix incorrect release timezone determination (f802446)
📖 Documentation¶
- configuration: Add description of allow-zero-version configuration option (4028f83)
- configuration: Clarify the major_on_zero configuration option (f7753cd)
⚙️ Build System¶
- •
- deps: Add click-option-group for grouping exclusive flags (bd892b8)
v9.1.1 (2024-02-25)¶
🪲 Bug Fixes¶
- •
- parse_git_url: Fix bad url with dash (1c25b8e)
v9.1.0 (2024-02-14)¶
✨ Features¶
- •
- Add bitbucket hvcs (bbbbfeb)
🪲 Bug Fixes¶
- •
- Remove unofficial environment variables (a5168e4)
📖 Documentation¶
- Add bitbucket authentication (b78a387)
- Add bitbucket to token table (56f146d)
- Fix typo (b240e12)
⚙️ Build System¶
- •
- deps: Bump minimum required tomlkit to >=0.11.0, closes #834 (291aace)
v9.0.3 (2024-02-08)¶
🪲 Bug Fixes¶
- •
- algorithm: Correct bfs to not abort on previously visited node (02df305)
⚡ Performance Improvements¶
- •
- algorithm: Refactor bfs search to use queue rather than recursion (8b742d3)
v9.0.2 (2024-02-08)¶
🪲 Bug Fixes¶
- •
- util: Properly parse windows line-endings in commit messages, closes #820 (70193ba)
📖 Documentation¶
- •
- Remove duplicate note in configuration.rst (PR#807, fb6f243)
v9.0.1 (2024-02-06)¶
🪲 Bug Fixes¶
- •
- config: Set commit parser opt defaults based on parser choice (PR#782, 9c594fb)
v9.0.0 (2024-02-06)¶
♻️ Refactoring¶
- •
- Drop support for Python 3.7 (PR#828, ad086f5)
💥 BREAKING CHANGES¶
- Removed Python 3.7 specific control flows and made more modern implementations the default control flow without a bypass or workaround. Will break on Python 3.7 now. If you require Python 3.7, you should lock your major version at v8. Since we only have enough manpower to maintain the latest major release, unfortunately there will not be any more updates to v8.
- We decided to remove support for Python 3.7 because it has been officially deprecated by the Python Foundation over a year ago and our codebase is starting to have limitations and custom implementations just to maintain support for 3.7.
v8.7.2 (2024-01-03)¶
🪲 Bug Fixes¶
- •
- lint: Correct linter errors (c9556b0)
v8.7.1 (2024-01-03)¶
🪲 Bug Fixes¶
- •
- cli-generate-config: Ensure configuration types are always toml parsable (PR#785, 758e649)
📖 Documentation¶
- Add note on default envvar behavior (PR#780, 0b07cae)
- configuration: Change defaults definition of token default to table (PR#786, df1df0d)
- contributing: Add docs-build, testing conf, & build instructions (PR#787, 011b072)
v8.7.0 (2023-12-22)¶
✨ Features¶
- •
- config: Enable default environment token per hvcs (PR#774, 26528eb)
v8.6.0 (2023-12-22)¶
✨ Features¶
- •
- utils: Expand parsable valid git remote url formats (PR#771, cf75f23)
📖 Documentation¶
- •
- Minor correction to commit-parsing documentation (PR#777, 245e878)
v8.5.2 (2023-12-19)¶
🪲 Bug Fixes¶
- •
- cli: Gracefully output configuration validation errors (PR#772, e8c9d51)
v8.5.1 (2023-12-12)¶
🪲 Bug Fixes¶
- cmd-version: Handle committing of git-ignored file gracefully (PR#764, ea89fa7)
- config: Cleanly handle repository in detached HEAD state (PR#765, ac4f9aa)
- config: Gracefully fail when repo is in a detached HEAD state (PR#765, ac4f9aa)
- version: Only commit non git-ignored files during version commit (PR#764, ea89fa7)
📖 Documentation¶
- configuration: Adjust wording and improve clarity (PR#766, 6b2fc8c)
- configuration: Fix typo in text (PR#766, 6b2fc8c)
v8.5.0 (2023-12-07)¶
✨ Features¶
- •
- Allow template directories to contain a '.' at the top-level (PR#762, 07b232a)
v8.4.0 (2023-12-07)¶
✨ Features¶
- cmd-version: Add --tag/--no-tag option to version command (PR#752, de6b9ad)
- version: Add --no-tag option to turn off tag creation (PR#752, de6b9ad)
🪲 Bug Fixes¶
- •
- version: Separate push tags from commit push when not committing changes (PR#752, de6b9ad)
📖 Documentation¶
- commands: Update version subcommand options (PR#752, de6b9ad)
- migration: Fix comments about publish command (PR#747, 90380d7)
v8.3.0 (2023-10-23)¶
✨ Features¶
- •
- action: Use composite action for semantic release (PR#692, 4648d87)
v8.2.0 (2023-10-23)¶
✨ Features¶
- •
- Allow user customization of release notes template (PR#736, 94a1311)
📖 Documentation¶
- •
- Add PYTHONPATH mention for commit parser (3284258)
v8.1.2 (2023-10-13)¶
🪲 Bug Fixes¶
- Correct lint errors (a13a6c3)
- Error when running build command on windows systems (PR#732, 2553657)
v8.1.1 (2023-09-19)¶
🪲 Bug Fixes¶
- •
- Attribute error when logging non-strings (PR#711, 75e6e48)
v8.1.0 (2023-09-19)¶
✨ Features¶
- •
- Upgrade pydantic to v2 (PR#714, 5a5c5d0)
📖 Documentation¶
- Fix typos (PR#708, 2698b0e)
- Update project urls (PR#715, 5fd5485)
v8.0.8 (2023-08-26)¶
🪲 Bug Fixes¶
- •
- Dynamic_import() import path split (PR#686, 1007a06)
v8.0.7 (2023-08-16)¶
🪲 Bug Fixes¶
- •
- Use correct upload url for github (PR#661, 8a515ca)
v8.0.6 (2023-08-13)¶
🪲 Bug Fixes¶
- •
- publish: Improve error message when no tags found (PR#683, bdc06ea)
v8.0.5 (2023-08-10)¶
🪲 Bug Fixes¶
- •
- Don't warn about vcs token if ignore_token_for_push is true. (PR#670, f1a54a6)
📖 Documentation¶
- password should be token. (PR#670, f1a54a6)
- Fix typo missing 's' in version_variable[s] in configuration.rst (PR#668, 879186a)
v8.0.4 (2023-07-26)¶
🪲 Bug Fixes¶
- •
- changelog: Use version as semver tag by default (PR#653, 5984c77)
📖 Documentation¶
- Add Python 3.11 to classifiers in metadata (PR#651, 5a32a24)
- Clarify usage of assets config option (PR#655, efa2b30)
v8.0.3 (2023-07-21)¶
🪲 Bug Fixes¶
- •
- Skip non-parsable versions when calculating next version (PR#649, 88f25ea)
v8.0.2 (2023-07-18)¶
🪲 Bug Fixes¶
- •
- Handle missing configuration (PR#644, f15753c)
📖 Documentation¶
- Better description for tag_format usage (2129b72)
- Clarify v8 breaking changes in GitHub action inputs (PR#643, cda050c)
- Correct version_toml example in migrating_from_v7.rst (PR#641, 325d5e0)
v8.0.1 (2023-07-17)¶
🪲 Bug Fixes¶
- •
- Invalid version in Git history should not cause a release failure (PR#632, 254430b)
📖 Documentation¶
- Reduce readthedocs formats and add entries to migration from v7 guide (9b6ddfe)
- migration: Fix hyperlink (PR#631, 5fbd52d)
v8.0.0 (2023-07-16)¶
✨ Features¶
- publish-cmd: Add --post-to-release-tag option to control where to publish (PR#619, ec30564)
- Make it easier to access commit messages in ParsedCommits (PR#619, ec30564)
- Remove publication of dists/ to artifact repository (PR#619, ec30564)
- Rename 'upload' configuration section to 'publish' (PR#619, ec30564)
- github-action: Add GitHub Actions output variables (PR#619, ec30564)
- version-cmd: Add --skip-build option (PR#619, ec30564)
- version-cmd Add --strict version mode (PR#619, ec30564)
🪲 Bug Fixes¶
- Add logging for token auth, use token for push (PR#619, ec30564)
- Caching for repo owner and name (PR#619, ec30564)
- Correct assets type in configuration (PR#619, ec30564)
- Correct assets type-annotation for RuntimeContext (PR#619, ec30564)
- Correct Dockerfile CLI command and GHA fetch (PR#619, ec30564)
- Correct handling of build commands (PR#619, ec30564)
- Correct logic for generating release notes (PR#619, ec30564)
- Create_or_update_release for Gitlab hvcs (PR#619, ec30564)
- Make additional attributes available for template authors (PR#619, ec30564)
- Only call Github Action output callback once defaults are set (PR#619, ec30564)
- Remove commit amending behavior (PR#619, ec30564)
- Resolve branch checkout logic in GHA (PR#619, ec30564)
- Resolve bug in changelog logic, enable upload to pypi (PR#619, ec30564)
- Resolve loss of tag_format configuration (PR#619, ec30564)
- github-action: Pin Debian version in Dockerfile (PR#619, ec30564)
- github-action: Correct input parsing (PR#619, ec30564)
- github-action: Mark container fs as safe for git to operate on (PR#619, ec30564)
- github-action: Quotation for git config command (PR#619, ec30564)
- github-action: Remove default for 'force' (PR#619, ec30564)
📖 Documentation¶
- Convert to Furo theme (PR#619, ec30564)
- Fix typo (PR#619, ec30564)
- Remove reference to dist publication (PR#619, ec30564)
- Update docs with additional required permissions (PR#619, ec30564)
- changelog-templates: fix typo (PR#619, ec30564)
♻️ Refactoring¶
- •
- Remove verify-ci command (PR#619, ec30564)
💥 BREAKING CHANGES¶
- •
- numerous breaking changes, see Upgrading to v8 for more information
v7.34.6 (2023-06-17)¶
🪲 Bug Fixes¶
- •
- Relax invoke dependency constraint (18ea200)
v7.34.5 (2023-06-17)¶
🪲 Bug Fixes¶
- •
- Consider empty commits (PR#608, 6f2e890)
v7.34.4 (2023-06-15)¶
🪲 Bug Fixes¶
- •
- Docker build fails installing git (PR#605, 9e3eb97)
v7.34.3 (2023-06-01)¶
🪲 Bug Fixes¶
- •
- Generate markdown linter compliant changelog headers & lists (PR#597, cc87400)
v7.34.2 (2023-05-29)¶
🪲 Bug Fixes¶
- •
- Open all files with explicit utf-8 encoding (PR#596, cb71f35)
v7.34.1 (2023-05-28)¶
🪲 Bug Fixes¶
- •
- Generate markdown linter compliant changelog headers & lists (PR#594, 9d9d403)
v7.34.0 (2023-05-28)¶
✨ Features¶
- •
- Add option to only parse commits for current working directory (PR#509, cdf8116)
v7.33.5 (2023-05-19)¶
🪲 Bug Fixes¶
- Update docs and default config for gitmoji changes (PR#590, 192da6e)
- Update sphinx dep (PR#590, 192da6e)
📖 Documentation¶
- •
- Update broken badge and add links (PR#591, 0c23447)
v7.33.4 (2023-05-14)¶
🪲 Bug Fixes¶
- •
- If prerelease, publish prerelease (PR#587, 927da9f)
v7.33.3 (2023-04-24)¶
🪲 Bug Fixes¶
- Trim emojis from config (PR#583, 02902f7)
- Update Gitmojis according to official node module (PR#582, 806fcfa)
📖 Documentation¶
- Grammar in docs/troubleshooting.rst (PR#557, bbe754a)
- Spelling and grammar in travis.rst (PR#556, 3a76e9d)
- Update repository name (PR#559, 5cdb05e)
v7.33.2 (2023-02-17)¶
🪲 Bug Fixes¶
- •
- Inconsistent versioning between print-version and publish (PR#524, 17d60e9)
v7.33.1 (2023-02-01)¶
🪲 Bug Fixes¶
- •
- action: Mark container fs as safe for git (PR#552, 2a55f68)
v7.33.0 (2023-01-15)¶
✨ Features¶
- Add signing options to action (31ad5eb)
- Update action with configuration options (PR#518, 4664afe)
- repository: Add support for TWINE_CERT, closes #521 (PR#522, d56e85d)
🪲 Bug Fixes¶
- Changelog release commit search logic (PR#530, efb3410)
- github-actions: Bump Dockerfile to use Python 3.10 image, closes #533 (PR#536, 8f2185d)
- action: Fix environment variable names (3c66218)
📖 Documentation¶
- •
- Update documentation (5cbdad2)
v7.32.2 (2022-10-22)¶
🪲 Bug Fixes¶
- •
- Fix changelog generation in tag-mode (PR#171, 482a62e)
📖 Documentation¶
- •
- Fix code blocks (PR#506, 24b7673)
v7.32.1 (2022-10-07)¶
🪲 Bug Fixes¶
- •
- Corrections for deprecation warnings (PR#505, d47afb6)
📖 Documentation¶
- •
- Correct spelling mistakes (PR#504, 3717e0d)
v7.32.0 (2022-09-25)¶
✨ Features¶
- •
- Add setting for enforcing textual changelog sections, closes #498 (PR#502, 988437d)
📖 Documentation¶
- •
- Correct documented default behavior for commit_version_number (PR#497, ffae2dc)
v7.31.4 (2022-08-23)¶
🪲 Bug Fixes¶
- •
- Account for trailing newlines in commit messages, closes #490 (PR#495, 111b151)
v7.31.3 (2022-08-22)¶
🪲 Bug Fixes¶
- •
- Use commit_subject when searching for release commits (PR#488, 3849ed9)
v7.31.2 (2022-07-29)¶
🪲 Bug Fixes¶
- Add better handling of missing changelog placeholder, closes #454 (e7a0e81)
- Add repo=None when not in git repo, closes #422 (40be804)
📖 Documentation¶
- •
- Add example for pyproject.toml (2a4b8af)
v7.31.1 (2022-07-29)¶
🪲 Bug Fixes¶
- •
- Update git email in action, closes #473 (0ece6f2)
v7.31.0 (2022-07-29)¶
✨ Features¶
- Add prerelease-patch and no-prerelease-patch flags for whether to auto-bump prereleases (b4e5b62)
- Override repository_url w REPOSITORY_URL env var (PR#439, cb7578c)
🪲 Bug Fixes¶
v7.30.2 (2022-07-26)¶
🪲 Bug Fixes¶
- •
- Declare additional_options as action inputs (PR#481, cb5d8c7)
v7.30.1 (2022-07-25)¶
🪲 Bug Fixes¶
- •
- Don't use commit_subject for tag pattern matching (PR#480, ac3f11e)
v7.30.0 (2022-07-25)¶
✨ Features¶
- •
- Add additional_options input for GitHub Action (PR#477, aea60e3)
🪲 Bug Fixes¶
- •
- Allow empty additional options (PR#479, c9b2514)
v7.29.7 (2022-07-24)¶
🪲 Bug Fixes¶
- •
- Ignore dependency version bumps when parsing version from commit logs (PR#476, 51bcb78)
v7.29.6 (2022-07-15)¶
🪲 Bug Fixes¶
- •
- Allow changing prerelease tag using CLI flags (PR#466, 395bf4f)
v7.29.5 (2022-07-14)¶
🪲 Bug Fixes¶
- Add packaging module requirement (PR#469, b99c9fa)
- publish: Get version bump for current release (PR#467, dd26888)
v7.29.4 (2022-06-29)¶
🪲 Bug Fixes¶
- •
- Add text for empty ValueError (PR#461, 733254a)
v7.29.3 (2022-06-26)¶
🪲 Bug Fixes¶
- •
- Ensure that assets can be uploaded successfully on custom GitHub servers (PR#458, 32b516d)
v7.29.2 (2022-06-20)¶
🪲 Bug Fixes¶
- •
- Ensure should_bump checks against release version if not prerelease (PR#457, da0606f)
v7.29.1 (2022-06-01)¶
🪲 Bug Fixes¶
- •
- Capture correct release version when patch has more than one digit (PR#448, 426cdc7)
v7.29.0 (2022-05-27)¶
✨ Features¶
- Allow using ssh-key to push version while using token to publish to hvcs (PR#419, 7b2dffa)
- config: Add ignore_token_for_push param (PR#419, 7b2dffa)
🪲 Bug Fixes¶
- Fix and refactor prerelease (PR#435, 94c9494)
- test: Override GITHUB_ACTOR env (PR#419, 7b2dffa)
📖 Documentation¶
- •
- Add documentation for ignore_token_for_push (PR#419, 7b2dffa)
v7.28.1 (2022-04-14)¶
🪲 Bug Fixes¶
- •
- Fix getting current version when version_source=tag_only (PR#437, b247936)
v7.28.0 (2022-04-11)¶
✨ Features¶
- •
- Add tag_only option for version_source, closes #354 (PR#436, cf74339)
v7.27.1 (2022-04-03)¶
🪲 Bug Fixes¶
- •
- prerelease: Pass prerelease option to get_current_version (PR#432, aabab0b)
v7.27.0 (2022-03-15)¶
✨ Features¶
- •
- Add git-lfs to docker container (PR#427, 184e365)
v7.26.0 (2022-03-07)¶
✨ Features¶
- publish-cmd: add --prerelease cli flag to enable prerelease versioning (PR#413, 7064265)
- version-cmd: add --prerelease cli flag to enable prerelease versioning (PR#413, 7064265)
📖 Documentation¶
- •
- Added basic info about prerelease versioning (PR#413, 7064265)
v7.25.2 (2022-02-24)¶
🪲 Bug Fixes¶
- •
- gitea: Use form-data from asset upload (PR#421, e011944)
v7.25.1 (2022-02-23)¶
🪲 Bug Fixes¶
- gitea: Build status and asset upload (PR#420, 57db81f)
- gitea: Handle list build status response (PR#420, 57db81f)
v7.25.0 (2022-02-17)¶
✨ Features¶
- •
- hvcs: Add gitea support (PR#412, b7e7936)
📖 Documentation¶
- •
- Document tag_commit, closes #410 (b631ca0)
v7.24.0 (2022-01-24)¶
✨ Features¶
- •
- Include additional changes in release commits (3e34f95)
v7.23.0 (2021-11-30)¶
✨ Features¶
- •
- Support Github Enterprise server (b4e01f1)
v7.22.0 (2021-11-21)¶
✨ Features¶
- •
- parser_angular: Allow customization in parser (298eebb)
🪲 Bug Fixes¶
- •
- Address PR feedback for parser_angular.py (f7bc458)
v7.21.0 (2021-11-21)¶
✨ Features¶
- •
- Use gitlab-ci or github actions env vars, closes #363 (8ca8dd4)
🪲 Bug Fixes¶
- •
- Remove invalid repository exception (746b62d)
v7.20.0 (2021-11-21)¶
✨ Features¶
- Allow custom environment variable names (PR#392, 372cda3)
- Rewrite Twine adapter for uploading to artifact repositories (cfb20af)
🪲 Bug Fixes¶
- Don't use linux commands on windows (PR#393, 5bcccd2)
- Mypy errors in vcs_helpers (13ca0fe)
- Skip removing the build folder if it doesn't exist (8e79fdc)
📖 Documentation¶
- •
- Clean typos and add section for repository upload (1efa18a)
v7.19.2 (2021-09-04)¶
🪲 Bug Fixes¶
- •
- Fixed ImproperConfig import error (PR#377, b011a95)
v7.19.1 (2021-08-17)¶
🪲 Bug Fixes¶
- •
- Add get_formatted_tag helper instead of hardcoded v-prefix in the git tags (1a354c8)
v7.19.0 (2021-08-16)¶
✨ Features¶
- •
- Custom git tag format support (PR#373, 1d76632)
📖 Documentation¶
- configuration: define tag_format usage & resulting effect (PR#373, 1d76632)
- parser: Documentation for scipy-parser (45ee34a)
v7.18.0 (2021-08-09)¶
✨ Features¶
- •
- Add support for non-prefixed tags (PR#366, 0fee4dd)
📖 Documentation¶
- •
- Clarify second argument of ParsedCommit (086ddc2)
v7.17.0 (2021-08-07)¶
✨ Features¶
- •
- parser: Add scipy style parser (PR#369, 51a3921)
v7.16.4 (2021-08-03)¶
🪲 Bug Fixes¶
- •
- Correct rendering of gitlab issue references, closes #358 (07429ec)
v7.16.3 (2021-07-29)¶
🪲 Bug Fixes¶
- •
- Print right info if token is not set, closes #360 (PR#361, a275a7a)
v7.16.2 (2021-06-25)¶
🪲 Bug Fixes¶
- •
- Use release-api for gitlab (1ef5cab)
📖 Documentation¶
- Recommend setting a concurrency group for GitHub Actions (34b0735)
- Update trove classifiers to reflect supported versions (PR#344, 7578004)
v7.16.1 (2021-06-08)¶
🪲 Bug Fixes¶
- •
- Tomlkit should stay at 0.7.0 (769a5f3)
v7.16.0 (2021-06-08)¶
✨ Features¶
- •
- Add option to omit tagging (PR#341, 20603e5)
v7.15.6 (2021-06-08)¶
🪲 Bug Fixes¶
- •
- Update click and tomlkit (PR#339, 947ea3b)
v7.15.5 (2021-05-26)¶
🪲 Bug Fixes¶
- •
- Pin tomlkit to 0.7.0 (2cd0db4)
v7.15.4 (2021-04-29)¶
🪲 Bug Fixes¶
- •
- Change log level of failed toml loading, closes #235 (24bb079)
v7.15.3 (2021-04-03)¶
🪲 Bug Fixes¶
- •
- Add venv to path in github action (583c5a1)
v7.15.2 (2021-04-03)¶
🪲 Bug Fixes¶
- Run semantic-release in virtualenv in the github action, closes #331 (b508ea9)
- Set correct path for venv in action script (aac02b5)
- Use absolute path for venv in github action (d4823b3)
📖 Documentation¶
- •
- Clarify that HVCS should be lowercase, closes #330 (da0ab0c)
v7.15.1 (2021-03-26)¶
🪲 Bug Fixes¶
- Add support for setting build_command to "false", closes #328 (520cf1e)
- Upgrade python-gitlab range, closes #329 (abfacc4)
📖 Documentation¶
- •
- Add common options to documentation, closes #327 (20d79a5)
v7.15.0 (2021-02-18)¶
✨ Features¶
- •
- Allow the use of .pypirc for twine uploads (PR#325, 6bc56b8)
📖 Documentation¶
- •
- Add documentation for releasing on a Jenkins instance (PR#324, 77ad988)
v7.14.0 (2021-02-11)¶
✨ Features¶
- •
- checks: Add support for Jenkins CI (PR#322, 3e99855)
📖 Documentation¶
- Correct casing on proper nouns (PR#320, d51b999)
- Correcting Python casing (PR#320, d51b999)
- Correcting Semantic Versioning casing (PR#320, d51b999)
v7.13.2 (2021-01-29)¶
🪲 Bug Fixes¶
- Crash when TOML has no PSR section (PR#319, 5f8ab99)
- Fix crash when TOML has no PSR section (PR#319, 5f8ab99)
📖 Documentation¶
- •
- Fix version_toml example for Poetry (PR#318, 39acb68)
v7.13.1 (2021-01-26)¶
🪲 Bug Fixes¶
- •
- Use multiline version_pattern match in replace, closes #306 (PR#315, 1a85af4)
v7.13.0 (2021-01-26)¶
✨ Features¶
- •
- Support toml files for version declaration, closes #245, #275 (PR#307, 9b62a7e)
v7.12.0 (2021-01-25)¶
✨ Features¶
- •
- github: Retry GitHub API requests on failure (PR#314, ac241ed)
🪲 Bug Fixes¶
- •
- github: Add retries to github API requests (PR#314, ac241ed)
📖 Documentation¶
- •
- actions: Pat must be passed to checkout step too, closes #311 (e2d8e47)
v7.11.0 (2021-01-08)¶
✨ Features¶
- •
- print-version: Add print-version command to output version (512e3d9)
🪲 Bug Fixes¶
- Add dot to --define option help (eb4107d)
- Avoid Unknown bump level 0 message (8ab624c)
- actions: Fix github actions with new main location (6666672)
⚙️ Build System¶
- •
- Add __main__.py magic file (e93f36a)
v7.10.0 (2021-01-08)¶
✨ Features¶
- •
- build: Allow falsy values for build_command to disable build step (c07a440)
📖 Documentation¶
- Fix incorrect reference syntax (42027f0)
- Rewrite getting started page (97a9046)
v7.9.0 (2020-12-21)¶
✨ Features¶
- •
- hvcs: Add hvcs_domain config option, closes #277 (ab3061a)
🪲 Bug Fixes¶
- history: Coerce version to string (PR#298, d4cdc3d)
- history: Require semver >= 2.10 (5087e54)
v7.8.2 (2020-12-19)¶
✨ Features¶
- •
- repository: Add to settings artifact repository (f4ef373)
🪲 Bug Fixes¶
- •
- cli: Skip remove_dist where not needed (04817d4)
v7.8.1 (2020-12-18)¶
🪲 Bug Fixes¶
- Filenames with unknown mimetype are now properly uploaded to github release (f3ece78)
- logs: Fix TypeError when enabling debug logs (2591a94)
v7.8.0 (2020-12-18)¶
✨ Features¶
- •
- Add upload_to_pypi_glob_patterns option (42305ed)
🪲 Bug Fixes¶
- changelog: Use "issues" link vs "pull" (93e48c9)
- netrc: Prefer using token defined in GH_TOKEN instead of .netrc file (3af32a7)
v7.7.0 (2020-12-12)¶
✨ Features¶
- •
- changelog: Add PR links in markdown (PR#282, 0448f6c)
v7.6.0 (2020-12-06)¶
✨ Features¶
- •
- Add major_on_zero option (d324154)
📖 Documentation¶
- •
- Add documentation for option major_on_zero (2e8b26e)
v7.5.0 (2020-12-04)¶
✨ Features¶
- •
- logs: Include scope in changelogs (PR#281, 21c96b6)
v7.4.1 (2020-12-04)¶
🪲 Bug Fixes¶
- •
- Add "changelog_capitalize" to flags, closes #278 (PR#279, 37716df)
v7.4.0 (2020-11-24)¶
✨ Features¶
- •
- Add changelog_capitalize configuration, closes #260 (7cacca1)
📖 Documentation¶
- Fix broken internal references (PR#270, da20b9b)
- Update links to Github docs (PR#268, c53162e)
v7.3.0 (2020-09-28)¶
✨ Features¶
- •
- Generate changelog.md file (PR#266, 2587dfe)
📖 Documentation¶
- •
- Fix docstring (5a5e2cf)
v7.2.5 (2020-09-16)¶
🪲 Bug Fixes¶
- •
- Add required to inputs in action metadata (PR#264, e76b255)
v7.2.4 (2020-09-14)¶
🪲 Bug Fixes¶
- •
- Use range for toml dependency, closes #241 (45707e1)
v7.2.3 (2020-09-12)¶
🪲 Bug Fixes¶
- •
- Support multiline version_pattern matching by default (82f7849)
📖 Documentation¶
- Create 'getting started' instructions (PR#256, 5f4d000)
- Link to getting started guide in README (f490e01)
v7.2.2 (2020-07-26)¶
🪲 Bug Fixes¶
- •
- changelog: Send changelog to stdout, closes #250 (87e2bb8)
📖 Documentation¶
- •
- Add quotation marks to the pip commands in CONTRIBUTING.rst (PR#253, e20fa43)
v7.2.1 (2020-06-29)¶
🪲 Bug Fixes¶
- •
- Commit all files with bumped versions (PR#249, b3a1766)
📖 Documentation¶
- •
- Give example of multiple build commands (PR#248, 65f1ffc)
v7.2.0 (2020-06-15)¶
✨ Features¶
- •
- Bump versions in multiple files, closes #175 (PR#246, 0ba2c47)
v7.1.1 (2020-05-28)¶
🪲 Bug Fixes¶
- •
- changelog: Swap sha and message in table changelog (6741370)
v7.1.0 (2020-05-24)¶
✨ Features¶
- •
- changelog: Add changelog_table component, closes #237 (PR#242, fe6a7e7)
v7.0.0 (2020-05-22)¶
✨ Features¶
- Pass changelog_sections to components (PR#240, 3e17a98)
- changelog: Add changelog components (PR#240, 3e17a98)
📖 Documentation¶
- Add conda-forge badge (e9536bb)
- Add documentation for changelog_components (PR#240, 3e17a98)
💥 BREAKING CHANGES¶
- •
- changelog: The compare_url option has been removed in favor of using changelog_components. This functionality is now available as the semantic_release.changelog.compare_url component.
v6.4.1 (2020-05-15)¶
🪲 Bug Fixes¶
- •
- Convert \r\n to \n in commit messages, closes #239 (34acbbc)
v6.4.0 (2020-05-15)¶
✨ Features¶
- •
- history: Create emoji parser (PR#238, 2e1c50a)
🪲 Bug Fixes¶
- Add emojis to default changelog_sections (PR#238, 2e1c50a)
- Include all parsed types in changelog (PR#238, 2e1c50a)
📖 Documentation¶
- •
- Add documentation for emoji parser (PR#238, 2e1c50a)
♻️ Refactoring¶
- •
- history: Get breaking changes in parser (PR#238, 2e1c50a)
v6.3.1 (2020-05-11)¶
🪲 Bug Fixes¶
- •
- Use getboolean for commit_version_number, closes #186 (a60e0b4)
v6.3.0 (2020-05-09)¶
✨ Features¶
- •
- history: Support linking compare page in changelog, closes #218 (79a8e02)
📖 Documentation¶
- Document compare_link option (e52c355)
- Rewrite commit-log-parsing.rst (4c70f4f)
v6.2.0 (2020-05-02)¶
✨ Features¶
- •
- history: Check all paragraphs for breaking changes, closes #200 (fec08f0)
📖 Documentation¶
- Add = to verbosity option, closes #227 (a0f4c9c)
- Use references where possible, closes #221 (f38e5d4)
v6.1.0 (2020-04-26)¶
✨ Features¶
- actions: Support PYPI_TOKEN on GitHub Actions (df2c080)
- pypi: Support easier use of API tokens, closes #213 (bac135c)
📖 Documentation¶
- •
- Add documentation for PYPI_TOKEN (a8263a0)
v6.0.1 (2020-04-15)¶
🪲 Bug Fixes¶
- •
- hvcs: Convert get_hvcs to use LoggedFunction (3084249)
v6.0.0 (2020-04-15)¶
📖 Documentation¶
- Create Read the Docs config file (aa5a1b7)
- Include README.rst in index.rst (8673a9d)
- Move action.rst into main documentation (509ccaf)
- Rewrite README.rst (e049772)
- Rewrite troubleshooting page (0285de2)
♻️ Refactoring¶
- •
- debug: Use logging and click_log instead of ndebug (15b1f65)
💥 BREAKING CHANGES¶
- •
- debug: debug="*" no longer has an effect, instead use --verbosity DEBUG.
v5.2.0 (2020-04-09)¶
✨ Features¶
- •
- github: Add tag as default release name (2997908)
📖 Documentation¶
- •
- Automate API docs (7d4fea2)
v5.1.0 (2020-04-04)¶
✨ Features¶
- •
- history: Allow customizing changelog_sections (PR#207, d5803d5)
📖 Documentation¶
- Improve formatting of configuration page (9a8e22e)
- Improve formatting of envvars page (b376a56)
- Update index.rst (b27c26c)
v5.0.3 (2020-03-26)¶
🪲 Bug Fixes¶
- Bump dependencies and fix Windows issues on Development (PR#173, 0a6f8c3)
- Missing mime types on Windows (PR#173, 0a6f8c3)
v5.0.2 (2020-03-22)¶
🪲 Bug Fixes¶
- •
- history: Leave case of other characters unchanged (96ba94c)
v5.0.1 (2020-03-22)¶
🪲 Bug Fixes¶
- •
- Make action use current version of semantic-release (123984d)
v5.0.0 (2020-03-22)¶
✨ Features¶
- •
- build: Allow config setting for build command, closes #188 (PR#195, 740f4bd)
🪲 Bug Fixes¶
- •
- Rename default of build_command config (d5db22f)
📖 Documentation¶
- •
- pypi: Update docstrings in pypi.py (6502d44)
💥 BREAKING CHANGES¶
- •
- build: Previously the build_commands configuration variable set the types of bundles sent to python setup.py. It has been replaced by the configuration variable build_command which takes the full command e.g. python setup.py sdist or poetry build.
v4.11.0 (2020-03-22)¶
✨ Features¶
- •
- actions: Create GitHub Action (350245d)
📖 Documentation¶
- Make AUTHORS.rst dynamic (db2e076)
- readme: Fix minor typo (c22f69f)
v4.10.0 (2020-03-03)¶
✨ Features¶
- •
- Make commit message configurable (PR#184, eb0762c)
v4.9.0 (2020-03-02)¶
✨ Features¶
- •
- pypi: Add build_commands config (22146ea)
🪲 Bug Fixes¶
- •
- pypi: Change bdist_wheels to bdist_wheel (c4db509)
v4.8.0 (2020-02-28)¶
✨ Features¶
- •
- git: Add a new config for commit author (aa2c22c)
v4.7.1 (2020-02-28)¶
🪲 Bug Fixes¶
- •
- Repair parsing of remotes in the gitlab ci format, closes #181 (0fddbe2)
v4.7.0 (2020-02-28)¶
✨ Features¶
- Upload distribution files to GitHub Releases (PR#177, e427658)
- github: Upload dists to release (PR#177, e427658)
🪲 Bug Fixes¶
- Post changelog after PyPI upload (PR#177, e427658)
- Support repository owner names containing dots, closes #179 (a6c4da4)
- github: Fix upload of .whl files (PR#177, e427658)
- github: Use application/octet-stream for .whl files (90a7e47)
📖 Documentation¶
- •
- Document upload_to_release config option (PR#177, e427658)
v4.6.0 (2020-02-19)¶
✨ Features¶
- •
- history: Capitalize changelog messages (1a8e306)
🪲 Bug Fixes¶
- Add more debug statements in logs (bc931ec)
- Only overwrite with patch if bump is None, closes #159 (1daa4e2)
v4.5.1 (2020-02-16)¶
🪲 Bug Fixes¶
- •
- github: Send token in request header, closes #167 (be9972a)
📖 Documentation¶
- Add note about automatic releases in readme (e606e75)
- Fix broken list in readme (7aa572b)
- Update readme and getting started docs (07b3208)
v4.5.0 (2020-02-08)¶
✨ Features¶
- •
- history: Enable colon defined version, closes #165 (7837f50)
🪲 Bug Fixes¶
- Remove erroneous submodule (762bfda)
- cli: --noop flag works when before command, closes #73 (4fcc781)
v4.4.1 (2020-01-18)¶
🪲 Bug Fixes¶
- •
- Add quotes around twine arguments, closes #163 (46a83a9)
v4.4.0 (2020-01-17)¶
✨ Features¶
- parser: Add support for exclamation point for breaking changes, closes #156 (a4f8a10)
- parser: Make BREAKING-CHANGE synonymous with BREAKING CHANGE (beedccf)
🪲 Bug Fixes¶
- •
- github: Add check for GITHUB_ACTOR for git push (PR#162, c41e9bb)
v4.3.4 (2019-12-17)¶
🪲 Bug Fixes¶
- •
- Fallback to whole log if correct tag is not available, closes #51 (PR#157, 252bffd)
v4.3.3 (2019-11-06)¶
🪲 Bug Fixes¶
- Instead of requiring click 7.0, looks like all tests will pass with at least 2.0. (PR#155, f07c7f6)
- Set version of click to >=2.0,<8.0. (PR#155, f07c7f6)
- Upgrade to click 7.0, closes #117 (PR#155, f07c7f6)
v4.3.2 (2019-10-05)¶
🪲 Bug Fixes¶
- •
- Update regex to get repository owner and name for project with dots, closes #151 (2778e31)
v4.3.1 (2019-09-29)¶
🪲 Bug Fixes¶
- •
- Support repo urls without git terminator (700e9f1)
v4.3.0 (2019-09-06)¶
✨ Features¶
- Add the possibility to load configuration from pyproject.toml (35f8bfe)
- Allow the override of configuration options from cli, closes #119 (f0ac82f)
- Allow users to get version from tag and write/commit bump to file, closes #104 (1f9fe1c)
- Make the vcs functionalities work with gitlab, closes #121 (82d555d)
🪲 Bug Fixes¶
- Manage subgroups in git remote url, closes #139, #140 (4b11875)
- Update list of commit types to include build, ci and perf, closes #145 (41ea12f)
v4.2.0 (2019-08-05)¶
✨ Features¶
- Add configuration to customize handling of dists, closes #115 (2af6f41)
- Add support for configuring branch, closes #43 (14abb05)
- Add support for showing unreleased changelog, closes #134 (41ef794)
🪲 Bug Fixes¶
- Add commit hash when generating breaking changes, closes #120 (0c74faf)
- Kept setting new version for tag source (0e24a56)
- Remove deletion of build folder, closes #115 (b45703d)
- Updated the tag tests (3303eef)
- Upgrade click to 7.0 (2c5dd80)
v4.1.2 (2019-08-04)¶
🪲 Bug Fixes¶
- Correct isort build fail (0037210)
- Make sure the history only breaks loop for version commit, closes #135 (5dc6cfc)
- vcs: Allow cli to be run from subdirectory (fb7bb14)
📖 Documentation¶
- •
- circleci: Point badge to master branch (9c7302e)
v4.1.1 (2019-02-15)¶
📖 Documentation¶
- Correct usage of changelog (f4f59b0)
- Debug usage and related (f08e594)
- Describing the commands (b6fa04d)
- Update url for commit guidelinesThe guidelines can now be found in theDEVELOPERS.md in angular. (90c1b21)
v4.1.0 (2019-01-31)¶
✨ Features¶
- •
- ci_checks: Add support for bitbucket (9fc120d)
🪲 Bug Fixes¶
- Initialize git Repo from current folder (c7415e6)
- Maintain version variable formatting on bump (PR#103, bf63156)
- Use same changelog code for command as post (248f622)
📖 Documentation¶
- Add installation instructions for development (PR#106, 9168d0e)
- readme: Add testing instructions (bb352f5)
v4.0.1 (2019-01-12)¶
🪲 Bug Fixes¶
- Add better error message when pypi credentials are empty, closes #96 (c4e5dcb)
- Clean out dist and build before building, closes #86 (b628e46)
- Filter out pypi secrets from exceptions, closes #41 (5918371)
- Unfreeze dependencies, closes #100 (847833b)
- Use correct syntax to exclude tests in package, closes #92 (3e41e91)
- parser_angular: Fix non-match when special chars in scope (8a33123)
📖 Documentation¶
- •
- Remove reference to gitter, closes #90 (896e37b)
v4.0.0 (2018-11-22)¶
✨ Features¶
- Add support for commit_message config variable (4de5400)
- CI checks: Add support for GitLab CI checks, closes #88 (8df5e2b)
🪲 Bug Fixes¶
- Add check of credentials (7d945d4)
- Add credentials check (0694604)
- Add dists to twine call (1cec2df)
- Change requests from fixed version to version range (PR#93, af3ad59)
- Re-add skip-existing (366e9c1)
- Remove repository argument in twine (e24543b)
- Remove universal from setup config (18b2402)
- Update twine (c4ae7b8)
- Use new interface for twine (c04872d)
- Use twine through cli call (ab84beb)
📖 Documentation¶
- Add type hints and more complete docstrings, closes #81 (a6d5e9b)
- Fix typo in documentation index (da6844b)
♻️ Refactoring¶
- •
- Remove support for python 2 (85fe638)
💥 BREAKING CHANGES¶
- If you rely on the commit message to be the version number only, this will break your code
- This will only work with python 3 after this commit.
v3.11.2 (2018-06-10)¶
🪲 Bug Fixes¶
- •
- Upgrade twine (9722313)
v3.11.1 (2018-06-06)¶
🪲 Bug Fixes¶
- •
- Change Gitpython version number, closes #80 (23c9d4b)
📖 Documentation¶
- •
- Add retry option to cli docs (021da50)
v3.11.0 (2018-04-12)¶
✨ Features¶
- Add --retry cli option (PR#78, 3e312c0)
- Add support to finding previous version from tags if not using commit messages (PR#68, 6786487)
- Be a bit more forgiving to find previous tags (PR#68, 6786487)
🪲 Bug Fixes¶
- Add pytest cache to gitignore (b8efd5a)
- Make repo non if it is not a git repository, closes #74 (1dc306b)
📖 Documentation¶
- Define --retry usage (3e312c0)
- Remove old notes about trello board (7f50c52)
- Update status badges (cfa13b8)
v3.10.3 (2018-01-29)¶
🪲 Bug Fixes¶
- •
- Error when not in git repository, closes #74 (PR#75, 251b190)
v3.10.2 (2017-08-03)¶
🪲 Bug Fixes¶
- •
- Update call to upload to work with twine 1.9.1 (PR#72, 8f47643)
v3.10.1 (2017-07-22)¶
🪲 Bug Fixes¶
- •
- Update Twine (PR#69, 9f268c3)
v3.10.0 (2017-05-05)¶
✨ Features¶
- •
- Add git hash to the changelog (PR#65, 628170e)
🪲 Bug Fixes¶
- •
- Make changelog problems not fail whole publish (b5a68cf)
📖 Documentation¶
- •
- Fix typo in cli.py docstring (PR#64, 0d13985)
v3.9.0 (2016-07-03)¶
✨ Features¶
- Add option for choosing between versioning by commit or tag (c0cd1f5)
- Don't use file to track version, only tag to commit for versioning (cd25862)
- Get repo version from historical tags instead of config file (a45a9bf)
🪲 Bug Fixes¶
- •
- Can't get the proper last tag from commit history (5a0e681)
v3.8.1 (2016-04-17)¶
🪲 Bug Fixes¶
- •
- Add search_parent_directories option to gitpython (PR#62, 8bf9ce1)
v3.8.0 (2016-03-21)¶
✨ Features¶
- •
- Add ci checks for circle ci (151d849)
🪲 Bug Fixes¶
- Add git fetch to frigg after success (74a6cae)
- Make tag parser work correctly with breaking changes (9496f6a)
- Refactoring cli.py to improve --help and error messages (c79fc34)
📖 Documentation¶
- Add info about correct commit guidelines (af35413)
- Add info about trello board in readme (5229557)
- Fix badges in readme (7f4e549)
- Update info about releases in contributing.md (466f046)
v3.7.2 (2016-03-19)¶
🪲 Bug Fixes¶
- •
- Move code around a bit to make flake8 happy (41463b4)
v3.7.1 (2016-03-15)¶
📖 Documentation¶
- •
- configuration: Fix typo in setup.cfg section (725d87d)
v3.7.0 (2016-01-10)¶
✨ Features¶
- •
- Add ci_checks for Frigg CI (577c374)
v3.6.1 (2016-01-10)¶
🪲 Bug Fixes¶
- •
- Add requests as dependency (4525a70)
v3.6.0 (2015-12-28)¶
✨ Features¶
- •
- Add checks for semaphore, closes #44 (2d7ef15)
📖 Documentation¶
- Add documentation for configuring on CI (7806940)
- Add note about node semantic release (0d2866c)
- Add step by step guide for configuring travis ci (6f23414)
- Move automatic-releases to subfolder (ed68e5b)
- Remove duplicate readme (42a9421)
v3.5.0 (2015-12-22)¶
✨ Features¶
- Add author in commit, closes #40 (020efaa)
- Checkout master before publishing (dc4077a)
🪲 Bug Fixes¶
- •
- Remove " from git push command (031318b)
📖 Documentation¶
- •
- Convert readme to rst (e8a8d26)
v3.4.0 (2015-12-22)¶
✨ Features¶
- •
- Add travis environment checks (f386db7)
v3.3.3 (2015-12-22)¶
🪲 Bug Fixes¶
- •
- Do git push and git push --tags instead of --follow-tags (8bc70a1)
v3.3.2 (2015-12-21)¶
🪲 Bug Fixes¶
- •
- Change build badge (0dc068f)
📖 Documentation¶
- •
- Update docstrings for generate_changelog (987c6a9)
v3.3.1 (2015-12-21)¶
🪲 Bug Fixes¶
- Add pandoc to travis settings (17d40a7)
- Only list commits from the last version tag, closes #28 (191369e)
v3.3.0 (2015-12-20)¶
✨ Features¶
- •
- Add support for environment variables for pypi credentials (3b383b9)
🪲 Bug Fixes¶
- Add missing parameters to twine.upload (4bae22b)
- Better filtering of github token in push error (9b31da4)
- Downgrade twine to version 1.5.0 (66df378)
- Make sure the github token is not in the output (55356b7)
- Push to master by default (a0bb023)
v3.2.1 (2015-12-20)¶
🪲 Bug Fixes¶
- Add requirements to manifest (ed25ecb)
- pypi: Add sdist as default in addition to bdist_wheel (a1a35f4)
v3.2.0 (2015-12-20)¶
✨ Features¶
- angular-parser: Remove scope requirement (90c9d8d)
- git: Add push to GH_TOKEN@github-url (546b5bf)
🪲 Bug Fixes¶
- •
- deps: Use one file for requirements (4868543)
v3.1.0 (2015-08-31)¶
✨ Features¶
- •
- pypi: Add option to disable pypi upload (f5cd079)
v3.0.0 (2015-08-25)¶
✨ Features¶
- •
- parser: Add tag parser (a7f392f)
🪲 Bug Fixes¶
- errors: Add exposing of errors in package (3662d76)
- version: Parse file instead for version (005dba0)
v2.1.4 (2015-08-24)¶
🪲 Bug Fixes¶
- •
- github: Fix property calls (7ecdeb2)
v2.1.3 (2015-08-22)¶
🪲 Bug Fixes¶
- •
- hvcs: Make Github.token an property (37d5e31)
📖 Documentation¶
- api: Update apidocs (6185380)
- parsers: Add documentation about commit parsers (9b55422)
- readme: Update readme with information about the changelog command (56a745e)
v2.1.2 (2015-08-20)¶
🪲 Bug Fixes¶
- •
- cli: Fix call to generate_changelog in publish (5f8bce4)
v2.1.1 (2015-08-20)¶
🪲 Bug Fixes¶
- •
- history: Fix issue in get_previous_version (f961786)
v2.1.0 (2015-08-20)¶
✨ Features¶
- •
- cli: Add the possibility to re-post the changelog (4d028e2)
🪲 Bug Fixes¶
- cli: Fix check of token in changelog command (cc6e6ab)
- github: Fix the github releases integration (f0c3c1d)
- history: Fix changelog generation (f010272)
v2.0.0 (2015-08-19)¶
✨ Features¶
- cli: Add command for printing the changelog (336b8bc)
- github: Add github release changelog helper (da18795)
- history: Add angular parser (91e4f0f)
- history: Add generate_changelog function (347f21a)
- history: Add markdown changelog formatter (d77b58d)
- history: Set angular parser as the default (c2cf537)
- publish: Add publishing of changelog to github (74324ba)
- settings: Add loading of current parser (7bd0916)
🪲 Bug Fixes¶
- cli: Change output indentation on changelog (2ca41d3)
- history: Fix level id's in angular parser (2918d75)
- history: Fix regex in angular parser (974ccda)
- history: Support unexpected types in changelog generator (13deacf)
💥 BREAKING CHANGES¶
- •
- history: The default parser is now angular. Thus, the default behavior of the commit log evaluator will change. From now on it will use the angular commit message spec to determine the new version.
v1.0.0 (2015-08-04)¶
💥 Breaking¶
- •
- Restructure helpers into history and pypi (00f64e6)
📖 Documentation¶
- •
- Add automatic publishing documentation, resolves #18 (58076e6)
v0.9.1 (2015-08-04)¶
🪲 Bug Fixes¶
- •
- Fix get_current_head_hash to ensure it only returns the hash (7c28832)
v0.9.0 (2015-08-03)¶
✨ Features¶
- •
- Add Python 2.7 support, resolves #10 (c05e13f)
v0.8.0 (2015-08-03)¶
✨ Features¶
- Add check_build_status option, resolves #5 (310bb93)
- Add get_current_head_hash in git helpers (d864282)
- Add git helper to get owner and name of repo (f940b43)
v0.7.0 (2015-08-02)¶
✨ Features¶
- •
- Add patch_without_tag option, resolves #6 (3734a88)
📖 Documentation¶
- •
- Set up sphinx based documentation, resolves #1 (41fba78)
v0.6.0 (2015-08-02)¶
✨ Features¶
- •
- Add twine for uploads to pypi, resolves #13 (eec2561)
v0.5.4 (2015-07-29)¶
🪲 Bug Fixes¶
- •
- Add python2 not supported warning (e84c4d8)
v0.5.3 (2015-07-28)¶
⚙️ Build System¶
- •
- Add wheel as a dependency (971e479)
v0.5.2 (2015-07-28)¶
🪲 Bug Fixes¶
- •
- Fix python wheel tag (f9ac163)
v0.5.1 (2015-07-28)¶
🪲 Bug Fixes¶
- •
- Fix push commands (8374ef6)
v0.5.0 (2015-07-28)¶
✨ Features¶
- •
- Add setup.py hook for the cli interface (c363bc5)
v0.4.0 (2015-07-28)¶
✨ Features¶
- •
- Add publish command (d8116c9)
v0.3.2 (2015-07-28)¶
- •
- No change
v0.3.1 (2015-07-28)¶
🪲 Bug Fixes¶
- •
- Fix wheel settings (1e860e8)
v0.3.0 (2015-07-27)¶
✨ Features¶
- •
- Add support for tagging releases (5f4736f)
🪲 Bug Fixes¶
- •
- Fix issue when version should not change (441798a)
v0.2.0 (2015-07-27)¶
✨ Features¶
- •
- added no-operation (--noop) mode (44c2039)
⚙️ Build System¶
- •
- Swapped pygit2 with gitpython to avoid libgit2 dependency (8165a2e)
v0.1.1 (2015-07-27)¶
🪲 Bug Fixes¶
- •
- Fix entry point (bd7ce7f)
v0.1.0 (2015-07-27)¶
- •
- Initial Release
Concepts¶
This section covers the core concepts of Python Semantic Release and how it works. Understanding these concepts will help you effectively use Python Semantic Release in your projects.
Getting Started¶
If you haven't done so already, install Python Semantic Release locally following the installation instructions.
If you are using a CI/CD service, you may not have to add Python Semantic Release to your project's dependencies permanently, but for the duration of this guide for the initial setup, you will need to have it installed locally.
Configuring PSR¶
Python Semantic Release ships with a reasonable default configuration but some aspects MUST be customized to your project. To view the default configuration, run the following command:
semantic-release generate-config
The output of the above command is the default configuration in TOML format without any modifications. If this is fine for your project, then you do not need to configure anything else.
PSR accepts overrides to the default configuration keys individually. If you don't define the key-value pair in your configuration file, the default value will be used.
By default, Python Semantic Release will look for configuration overrides in pyproject.toml under the TOML table [tool.semantic_release]. You may specify a different file using the -c/--config option, for example:
# In TOML format with top level table [semantic_release]
semantic-release -c releaserc.toml
# In JSON format with top level object key {"semantic_release": {}}
semantic-release -c releaserc.json
The easiest way to get started is to output the default configuration to a file, delete keys you do not need to override, and then edit the remaining keys to suit your project.
To set up in pyproject.toml, run the following command:
# In file redirect in bash semantic-release generate-config --pyproject >> pyproject.toml # Open your editor to edit the configuration vim pyproject.toml
SEE ALSO:
- cmd-generate-config
- Configuration
Configuring the Version Stamp Feature¶
One of the best features of Python Semantic Release is the ability to automatically stamp the new version number into your project files, so you don't have to manually update the version upon each release. The version that is stamped is automatically determined by Python Semantic Release from your commit messages which compliments automated versioning seamlessly.
The most crucial version stamp is the one in your project metadata, which is used by the Python Package Index (PyPI) and other package managers to identify the version of your package.
For Python projects, this is typically the version field in your pyproject.toml file. First, set up your project metadata with the base version value. If you are starting with a brand new project, set project.version = "0.0.0". If you are working on an existing project, set it to the last version number you released. Do not include any v prefix.
IMPORTANT:
Your project metadata might look like this in pyproject.toml:
[project] name = "my-package" version = "0.0.0" # Set this to the last released version or "0.0.0" for new projects description = "A sample Python package"
To configure PSR to automatically update this version number, you need to specify the file and value to update in your configuration. Since pyproject.toml uses TOML format, you will add the replacement specification to the tool.semantic_release.version_toml list. Update the following configuration in your pyproject.toml file to include the version variable location:
[tool.semantic_release] version_toml = ["pyproject.toml:project.version"] # Alternatively, if you are using poetry's 'version' key, then you would use: version_toml = ["pyproject.toml:tool.poetry.version"]
If you have other TOML files where you want to stamp the version, you can add them to the version_toml list as well. In the above example, there is an implicit assumption that you only want the version as the raw number format. If you want to specify the full tag value (e.g. v-prefixed version), then include :tf for "tag format" at the end of the version variable specification.
For non-TOML formatted files (such as JSON or YAML files), you can use the version_variables configuration key instead. This feature uses an advanced Regular Expression to find and replace the version variable in the specified files.
For Python files, its much more effective to use importlib instead which will allow you to dynamically import the version from your package metadata and not require your project to commit the version number bump to the repository. For example, in your package's base __init__.py
# my_package/__init__.py from importlib.metadata import version as get_version __version__ = get_version(__package__) # Note: __package__ must match your 'project.name' as defined in pyproject.toml
SEE ALSO:
- Configuration specification of version_toml
- Configuration specification of version_variables
Using PSR to Build your Project¶
PSR provides a convenient way to build your project artifacts as part of the versioning process now that you have stamped the version into your project files. To enable this, you will need to specify the build command in your configuration. This command will be executed after the next version has been determined, and stamped into your files but before a release tag has been created.
To set up the build command, add the following to your pyproject.toml file:
[tool.semantic_release] build_command = "python -m build --sdist --wheel ."
SEE ALSO:
- build_command - Configuration specification for the build command.
- build_command_env - Configuration specification for the build command environment variables.
Choosing a Commit Message Parser¶
PSR uses commit messages to determine the type of version bump that should be applied to your project. PSR supports multiple commit message parsing styles, allowing you to choose the one that best fits your project's needs. Choose one of the supported commit parsers defined in Commit Parsing, or provide your own and configure it in your pyproject.toml file.
Each commit parser has its own default configuration options so if you want to customize the parser behavior, you will need to specify the parser options you want to override.
[tool.semantic_release] commit_parser = "conventional" [tool.semantic_release.commit_parser_options] minor_tags = ["feat"] patch_tags = ["fix", "perf"] parse_squash_commits = true ignore_merge_commits = true
Choosing your Changelog¶
Prior to creating a release, PSR will generate a changelog from the commit messages of your project. The changelog is extremely customizable from the format to the content of each section. PSR ships with a default changelog template that will be used if you do not provide custom templates. The default should be sufficient for most projects and has its own set of configuration options.
For basic customization, you can choose either an traditional Markdown formatted changelog (default) or if you want to integrate with a Sphinx Documentation project, you can use the reStructuredText (RST) format. You can also choose the file name and location of where to write the default changelog.
To set your changelog location and changelog format, add the following to your pyproject.toml file:
[tool.semantic_release.changelog.default_templates] changelog_file = "docs/source/CHANGELOG.rst" output_format = "rst" # or "md" for Markdown format
Secondly, the more important aspect of configuring your changelog is to define Commit Exclusion Patterns or patterns that will be used to filter out commits from the changelog. PSR does NOT (yet) come with a built-in set of exclusion patterns, so you will need to define them yourself. These commit patterns should be in line with your project's commit parser configuration.
To set commit exclusion patterns for a conventional commits parsers, add the following to your pyproject.toml file:
[tool.semantic_release.changelog] # Recommended patterns for conventional commits parser that is scope aware exclude_commit_patterns = [
'''chore(?:\([^)]*?\))?: .+''',
'''ci(?:\([^)]*?\))?: .+''',
'''refactor(?:\([^)]*?\))?: .+''',
'''style(?:\([^)]*?\))?: .+''',
'''test(?:\([^)]*?\))?: .+''',
'''build\((?!deps\): .+)''',
'''Initial [Cc]ommit.*''', ]
SEE ALSO:
- Changelog - Customize your changelog
- changelog.mode - Choose the changelog mode ('update' or 'init')
- Migrating an Existing Changelog
Defining your Release Branches¶
PSR provides a powerful feature to manage release types across multiple branches which can allow you to configure your project to have different release branches for different purposes, such as pre-release branches, beta branches, and your stable releases.
NOTE:
To define an alpha pre-release branch when you are working on a fix or new feature, you can add the following to your pyproject.toml file:
[tool.semantic_release.branches.alpha] # Matches branches with the prefixes 'feat/', 'fix/', or 'perf/'. match = "^(feat|fix|perf)/.+" prerelease = true prerelease_token = "alpha"
Any time you execute semantic-release version on a branch with the prefix feat/, fix/, or perf/, PSR will determine if a version bump is needed and if so, the resulting version will be a pre-release version with the alpha token. For example,
| Branch | Version Bump | Current Version | Next Version |
| main | Patch | 1.0.0 | 1.0.1 |
| fix/bug-1 | Patch | 1.0.0 | 1.0.1-alpha.1 |
SEE ALSO:
- •
- Multibranch Releases - Learn about multi-branch releases and how to configure them.
Configuring VCS Releases¶
You can set up Python Semantic Release to create Releases in your remote version control system, so you can publish assets and release notes for your project.
In order to do so, you will need to place an authentication token in the appropriate environment variable so that Python Semantic Release can authenticate with the remote VCS to push tags, create releases, or upload files.
GitHub (GH_TOKEN)¶
For local publishing to GitHub, you should use a personal access token and store it in your environment variables. Specify the name of the environment variable in your configuration setting remote.token. The default is GH_TOKEN.
To generate a token go to https://github.com/settings/tokens and click on "Generate new token".
For Personal Access Token (classic), you will need the repo scope to write (ie. push) to the repository.
For fine-grained Personal Access Tokens, you will need the contents permission.
GitLab (GITLAB_TOKEN)¶
A personal access token from GitLab. This is used for authenticating when pushing tags, publishing releases etc. This token should be stored in the GITLAB_TOKEN environment variable.
Gitea (GITEA_TOKEN)¶
A personal access token from Gitea. This token should be stored in the GITEA_TOKEN environment variable.
Bitbucket (BITBUCKET_TOKEN)¶
Bitbucket does not support uploading releases but can still benefit from automated tags and changelogs. The user has three options to push changes to the repository:
- 1.
- Use SSH keys.
- 2.
- Use an App Secret, store the secret in the BITBUCKET_TOKEN environment variable and the username in BITBUCKET_USER.
- 3.
- Use an Access Token for the repository and store it in the BITBUCKET_TOKEN environment variable.
SEE ALSO:
- Changelog - customize your project's changelog.
- Custom Release Notes - customize the published release notes
- version --vcs-release/--no-vcs-release - enable/disable VCS release creation.
Testing your Configuration¶
It's time to test your configuration!
# 1. Run the command in no-operation mode to see what would happen semantic-release -v --noop version # 2. If the output looks reasonable, try to run the command without any history changes # '-vv' will give you verbose debug output, which is useful for troubleshooting # commit parsing issues. semantic-release -vv version --no-commit --no-tag # 3. Evaluate your repository to see the changes that were made but not committed # - Check the version number in your pyproject.toml # - Check the distribution files from the build command # - Check the changelog file for the new release notes # 4. If everything looks good, make sure to commit/save your configuration changes git add pyproject.toml git commit -m "chore(config): configure Python Semantic Release" # 5. Now, try to run the release command with your history changes but without pushing semantic-release -v version --no-push --no-vcs-release # 6. Check the result on your local repository git status git log --graph --decorate --all # 7a. If you are happy with the release history and resulting commit & tag, # reverse your changes before trying the full release command. git tag -d v0.0.1 # replace with the actual version you released git reset --hard HEAD~1 # 7b. [Optional] Once you have configured a remote VCS token, try # running the full release command to update the remote repository. semantic-release version --push --vcs-release # This is optional as you may not want a personal access token set up or make # make the release permanent yet.
SEE ALSO:
- cmd-version
- Increasing Verbosity
Configuring CI/CD¶
PSR is meant to help you release at speed! See our CI/CD Configuration guides under the Automated Releases section.
Commit Parsing¶
One of the core components of Python Semantic Release (PSR) is the commit parser. The commit parser is responsible for parsing a Project's Git Repository commit history to extract insights about project changes and make decisions based on this insight.
The primary decision that PSR makes based on the commit history is whether or not to release a new version of the project, and if so, what version number to release. This decision is made based on the commit message descriptions of the change impact introduced by the commit. The change impact describes the impact to the end consumers of the project. Depending on the type of change, the version number will be incremented according to the Semantic Versioning specification (semver). It is the commit parser's job to extract the change impact from the commit message to determine the severity of the changes and then subsequently determine the semver level that the version should be bumped to for the next release.
The commit parser is also responsible for interpreting other aspects of the commit message which can be used to generate a helpful and detailed changelog. This includes extracting the type of change, the scope of the change, any breaking change descriptions, any linked pull/merge request numbers, and any linked issue numbers.
PSR provides several built-in commit parsers to handle a variety of different commit message styles. If the built-in parsers do not meet your needs, you can write your own custom parser to handle your specific commit message style.
WARNING:
Other tools may not follow the same conventions as PSR's guideline extensions, so if you plan to use any similar programs in tandem with PSR, you should be aware of the differences in feature support and fall back to the official format guidelines if necessary.
----
Built-in Commit Parsers¶
The following parsers are built in to Python Semantic Release:
- ConventionalCommitParser
- ConventionalCommitMonorepoParser (available in v10.4.0+)
- AngularCommitParser (deprecated in v9.19.0)
- EmojiCommitParser
- ScipyCommitParser
- TagCommitParser (deprecated in v9.12.0)
----
Conventional Commits Parser¶
Introduced in v9.19.0
A parser that is designed to parse commits formatted according to the Conventional Commits Specification. The parser is implemented with the following logic in relation to PSR's core features:
- Version Bump Determination: This parser extracts the commit type from the subject line of the commit (the first line of a commit message). This type is matched against the configuration mapping to determine the level bump for the specific commit. If the commit type is not found in the configuration mapping, the commit is considered a non-parsable commit and will return it as a ParseError object and ultimately a commit of type "unknown". The configuration mapping contains lists of commit types that correspond to the level bump for each commit type. Some commit types are still valid do not trigger a level bump, such as "chore" or "docs". You can also configure the default level bump commit_parser_options.default_level_bump if desired. To trigger a major release, the commit message body must contain a paragraph that begins with BREAKING CHANGE:. This will override the level bump determined by the commit type.
- Changelog Generation: PSR will group commits in the changelog by the commit type used in the commit message. The commit type shorthand is converted to a more human-friendly section heading and then used as the version section title of the changelog and release notes. Under the section title, the parsed commit descriptions are listed out in full. If the commit includes an optional scope, then the scope is prefixed on to the first line of the commit description. If a commit has any breaking change prefixed paragraphs in the commit message body, those paragraphs are separated out into a "Breaking Changes" section in the changelog (Breaking Changes section is available from the default changelog in v9.15.0). Each breaking change paragraph is listed in a bulleted list format across the entire version. A single commit is allowed to have more than one breaking change prefixed paragraph (as opposed to the Conventional Commits Specification). Commits with an optional scope and a breaking change will have the scope prefixed on to the breaking change paragraph. Parsing errors will return a ParseError object and ultimately a commit of type "unknown". Unknown commits are consolidated into an "Unknown" section in the changelog by the default template. To remove unwanted commits from the changelog that normally are placed in the "unknown" section, consider the use of the configuration option changelog.exclude_commit_patterns to ignore those commit styles.
- Pull/Merge Request Identifier Detection: This parser implements PSR's Common Linked Merge Request Detection to identify and extract pull/merge request numbers. The parser will return a string value if a pull/merge request number is found in the commit message. If no pull/merge request number is found, the parser will return an empty string.
- Linked Issue Identifier Detection: This parser implements PSR's Common Issue Identifier Detection to identify and extract issue numbers. The parser will return a tuple of issue numbers as strings if any are found in the commit message. If no issue numbers are found, the parser will return an empty tuple.
- Squash Commit Evaluation: This parser implements PSR's Common Squash Commit Evaluation to identify and extract each commit message as a separate commit message within a single squashed commit. You can toggle this feature on/off via the commit_parser_options setting.
- Release Notice Footer Detection: This parser implements PSR's Common Release Notice Footer Detection, which is a custom extension to traditional Conventional Commits Specification to use the NOTICE keyword as a git footer to document additional release information that is not considered a breaking change.
Limitations:
- •
- Commits with the revert type are not currently supported. Track the implementation of this feature in the issue #402.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in defaults.
----
Conventional Commits Monorepo Parser¶
Introduced in v10.4.0
IMPORTANT:
This parser is an extension of the Conventional Commits Parser, designed specifically for monorepo environments. A monorepo environment is defined as a single source control repository that contains multiple packages, each of which can be released independently and may have different version numbers.
This parser introduces two new configuration options that determine which packages are affected by a commit. These options control whether a commit is considered for version determination, changelog generation, and other release actions for the relevant packages. The 2 new configuration options are path_filters and scope_prefix.
Features:
- Package Specific Commit Filtering: For monorepo support, this parser uses 2 filtering rules to determine if a commit should be considered for a specific package. The first rule is based on file paths that are changed in the commit and the second rule is based on the optional scope prefix defined in the commit message. If either rule matches, then the commit is considered relevant to that package and will be used in version determination, changelog generation, etc, for that package. If neither rule matches, then the commit is ignored for that package. File path filtering rules are applied first and are the primary way to determine package relevance. The path_filters option allows for specifying a list of file path patterns and will also support negated patterns to ignore specific paths that otherwise would be selected from the file glob pattern. Negated patterns are defined by prefixing the pattern with an exclamation point (!). File path filtering is quite effective by itself but to handle the edge cases, the parser has the scope_prefix configuration option to allow the developer to specifically define when the commit is relevant to the package. In monorepo setups, there are often shared files between packages (generally at the root project level) that are modified occasionally but not always relevant to the package being released. Since you do not want to define this path in the package configuration as it may not be relevant to the release, then this parser will look for a match with the scope prefix. The scope prefix is a regular expression that is used to match the text inside the scope field of a Conventional Commit. The scope prefix is optional and is used only if file path filtering does not match. Commits that have matching files in the commit will be considered relevant to the package regardless if a scope prefix exists or if it matches.
- Version Bump Determination: Once package-specific commit filtering is applied, the relevant commits are passed to the Conventional Commits Parser for evaluation and then used for version bump determination. See Conventional Commits Parser for details.
- Changelog Generation: Once package-specific commit filtering is applied, the relevant commits are passed to the Conventional Commits Parser for evaluation and then used for changelog generation. See Conventional Commits Parser for details.
- Pull/Merge Request Identifier Detection: Once package-specific commit filtering is applied, the relevant commits are passed to the Conventional Commits Parser for pull/merge request identifier detection. See Common Linked Merge Request Detection for details.
- Linked Issue Identifier Detection: Once package-specific commit filtering is applied, the relevant commits are passed to the Conventional Commits Parser for linked issue identifier detection. See Common Issue Identifier Detection for details.
- Squash Commit Evaluation: Squashed commits are separated out into individual commits with the same set of changed files BEFORE the package-specific commit filtering is applied. Each pseudo-commit is then subjected to the same filtering rules as regular commits. See Common Squash Commit Evaluation for details.
- Release Notice Footer Detection: Once package-specific commit filtering is applied, the relevant commits are passed to the Conventional Commits Parser for release notice footer detection. See Common Release Notice Footer Detection for details.
Limitations:
- •
- revert commit type is NOT supported, see Conventional Commits Parser's limitations for details.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in defaults.
----
Angular Commit Parser¶
WARNING:
A parser that is designed to parse commits formatted according to the Angular Commit Style Guidelines. The parser is implemented with the following logic in relation to how PSR's core features:
- Version Bump Determination: This parser extracts the commit type from the subject line of the commit (the first line of a commit message). This type is matched against the configuration mapping to determine the level bump for the specific commit. If the commit type is not found in the configuration mapping, the commit is considered a non-parsable commit and will return it as a ParseError object and ultimately a commit of type "unknown". The configuration mapping contains lists of commit types that correspond to the level bump for each commit type. Some commit types are still valid do not trigger a level bump, such as "chore" or "docs". You can also configure the default level bump commit_parser_options.default_level_bump if desired. To trigger a major release, the commit message body must contain a paragraph that begins with BREAKING CHANGE:. This will override the level bump determined by the commit type.
- Changelog Generation: PSR will group commits in the changelog by the commit type used in the commit message. The commit type shorthand is converted to a more human-friendly section heading and then used as the version section title of the changelog and release notes. Under the section title, the parsed commit descriptions are listed out in full. If the commit includes an optional scope, then the scope is prefixed on to the first line of the commit description. If a commit has any breaking change prefixed paragraphs in the commit message body, those paragraphs are separated out into a "Breaking Changes" section in the changelog (Breaking Changes section is available from the default changelog in v9.15.0). Each breaking change paragraph is listed in a bulleted list format across the entire version. A single commit is allowed to have more than one breaking change prefixed paragraph (as opposed to the Angular Commit Style Guidelines). Commits with an optional scope and a breaking change will have the scope prefixed on to the breaking change paragraph. Parsing errors will return a ParseError object and ultimately a commit of type "unknown". Unknown commits are consolidated into an "Unknown" section in the changelog by the default template. To remove unwanted commits from the changelog that normally are placed in the "unknown" section, consider the use of the configuration option changelog.exclude_commit_patterns to ignore those commit styles.
- Pull/Merge Request Identifier Detection: This parser implements PSR's Common Linked Merge Request Detection to identify and extract pull/merge request numbers. The parser will return a string value if a pull/merge request number is found in the commit message. If no pull/merge request number is found, the parser will return an empty string. Feature available in v9.13.0+.
- Linked Issue Identifier Detection: This parser implements PSR's Common Issue Identifier Detection to identify and extract issue numbers. The parser will return a tuple of issue numbers as strings if any are found in the commit message. If no issue numbers are found, the parser will return an empty tuple. Feature available in v9.15.0+.
- Squash Commit Evaluation: This parser implements PSR's Common Squash Commit Evaluation to identify and extract each commit message as a separate commit message within a single squashed commit. You can toggle this feature on/off via the commit_parser_options setting. Feature available in v9.17.0+.
- Release Notice Footer Detection: This parser implements PSR's Common Release Notice Footer Detection, which is a custom extension to traditional Angular Commit Style Guidelines to use the NOTICE keyword as a git footer to document additional release information that is not considered a breaking change. Feature available in v9.18.0+.
Limitations:
- •
- Commits with the revert type are not currently supported. Track the implementation of this feature in the issue #402.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in defaults.
----
Emoji Commit Parser¶
A parser that is designed to parse commits formatted to the Gitmoji Specification with a few additional features that the specification does not cover but provide similar functionality expected from a Semantic Release tool. As the Gitmoji Specification describes, the emojis can be specified in either the unicode format or the shortcode text format. See the Gitmoji Specification for the pros and cons for which format to use, but regardless, the configuration options must match the format used in the commit messages. The parser is implemented with the following logic in relation to how PSR's core features:
- Version Bump Determination: This parser only looks for emojis in the subject line of the commit (the first line of a commit message). If more than one emoji is found, the emoji configured with the highest priority is selected for the change impact for the specific commit. The emoji with the highest priority is the one configured in the major configuration option, followed by the minor, and patch in descending priority order. If no emoji is found in the subject line, the commit is classified as other and will default to the level bump defined by the configuration option commit_parser_options.default_level_bump.
- Changelog Generation: PSR will group commits in the changelog by the emoji type used in the commit message. The emoji is used as the version section title and the commit descriptions are listed under that section. No emojis are removed from the commit message so each will be listed in the changelog and release notes. When more than one emoji is found in the subject line of a commit, the emoji with the highest priority is the one that will influence the grouping of the commit in the changelog. Commits containing no emojis or non-configured emojis are consolidated into an "Other" section. To remove unwanted commits from the changelog that would normally be added into the "other" section, consider the use of the configuration option changelog.exclude_commit_patterns to ignore those commit styles.
- Pull/Merge Request Identifier Detection: This parser implements PSR's Common Linked Merge Request Detection to identify and extract pull/merge request numbers. The parser will return a string value if a pull/merge request number is found in the commit message. If no pull/merge request number is found, the parser will return an empty string. Feature available in v9.13.0+.
- Linked Issue Identifier Detection: [Disabled by default] This parser implements PSR's Common Issue Identifier Detection to identify and extract issue numbers. The parser will return a tuple of issue numbers as strings if any are found in the commit message. If no issue numbers are found, the parser will return an empty tuple. This feature is disabled by default since it is not a part of the Gitmoji Specification but can be enabled by setting the configuration option commit_parser_options.parse_linked_issues to true. Feature available in v9.15.0+.
- Squash Commit Evaluation: This parser implements PSR's Common Squash Commit Evaluation to identify and extract each commit message as a separate commit message within a single squashed commit. You can toggle this feature on/off via the commit_parser_options setting. Feature available in v9.17.0+.
- Release Notice Footer Detection: This parser implements PSR's Common Release Notice Footer Detection, which is a custom extension that uses the NOTICE keyword as a git footer to document additional release information that is not considered a breaking change. Feature available in v9.18.0+.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in defaults.
----
Scipy Commit Parser¶
A parser that is designed to parse commits formatted according to the Scipy Commit Style Guidelines. This is essentially a variation of the Angular Commit Style Guidelines with all different commit types. Because of this small variance, this parser only extends our Angular Commit Parser parser with pre-defined scipy commit types in the default Scipy Parser Options and all other features are inherited.
Limitations:
- •
- Commits with the REV type are not currently supported. Track the implementation of this feature in the issue #402.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in defaults.
----
Tag Commit Parser¶
WARNING:
The original parser from v1.0.0 of Python Semantic Release. Similar to the emoji parser above, but with less features.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in defaults.
----
Common Linked Merge Request Detection¶
Introduced in v9.13.0
All of the PSR built-in parsers implement common pull/merge request identifier detection logic to extract pull/merge request numbers from the commit message regardless of the VCS platform. The parsers evaluate the subject line for a parenthesis-enclosed number at the end of the line. PSR's parsers will return a string value if a pull/merge request number is found in the commit message. If no pull/merge request number is found, the parsers will return an empty string.
Examples:
All of the following will extract a MR number of "x123", where 'x' is the character prefix
- 1.
- BitBucket: Merged in feat/my-awesome-feature (pull request #123)
- 2.
- GitHub: feat: add new feature (#123)
- 3.
- GitLab: fix: resolve an issue (!123)
----
Common Issue Identifier Detection¶
Introduced in v9.15.0
All of the PSR built-in parsers implement common issue identifier detection logic, which is similar to many VCS platforms such as GitHub, GitLab, and BitBucket. The parsers will look for common issue closure text prefixes in the Git Trailer format in the commit message to identify and extract issue numbers. The detection logic is not strict to any specific issue tracker as we try to provide a flexible approach to identifying issue numbers but in order to be flexible, it is required to the use the Git Trailer format with a colon (:) as the token separator.
PSR attempts to support all variants of issue closure text prefixes, but not all will work for your VCS. PSR supports the following case-insensitive prefixes and their conjugations (plural, present, & past tense):
- close (closes, closing, closed)
- fix (fixes, fixing, fixed)
- resolve (resolves, resolving, resolved)
- implement (implements, implementing, implemented)
PSR also allows for a more flexible approach to identifying more than one issue number without the need of extra git trailers (although PSR does support multiple git trailers). PSR support various list formats which can be used to identify more than one issue in a list. This format will not necessarily work on your VCS. PSR currently support the following list formats:
- comma-separated (ex. Closes: #123, #456, #789)
- space-separated (ex. resolve: #123 #456 #789)
- semicolon-separated (ex. Fixes: #123; #456; #789)
- slash-separated (ex. close: #123/#456/#789)
- ampersand-separated (ex. Implement: #123 & #789)
- and-separated (ex. Resolve: #123 and #456 and #789)
- mixed (ex. Closed: #123, #456, and #789 or Fixes: #123, #456 & #789)
All the examples above use the most common issue number prefix (#) but PSR is flexible to support other prefixes used by VCS platforms or issue trackers such as JIRA (ex. ABC-###).
The parsers will return a tuple of issue numbers as strings if any are found in the commit message. Strings are returned to ensure that the any issue number prefix characters are preserved (ex. #123 or ABC-123). If no issue numbers are found, the parsers will return an empty tuple.
References:
- BitBucket: Resolving Issues Automatically
- GitHub: Linking Issue to PR
- GitLab: Default Closing Patterns
----
Common Release Notice Footer Detection¶
Introduced in v9.18.0*
All of the PSR built-in parsers implement common release notice footer detection logic to identify and extract a NOTICE git trailer that documents any additional release information the developer wants to provide to the software consumer. The idea extends from the concept of the BREAKING CHANGE: git trailer to document any breaking change descriptions but the NOTICE trailer is intended to document any information that is below the threshold of a breaking change while still important for the software consumer to be aware of. Common uses would be to provide deprecation warnings or more detailed change usage information for that release. Parsers will collapse single newlines after the NOTICE trailer into a single line paragraph. Commits may have more than one NOTICE trailer in a single commit message. Each ParsedCommit will have a release_notices attribute that is a tuple of string paragraphs to identify each release notice.
In the default changelog and release notes template, these release notices will be formatted into their own section called Additional Release Information. Each will include any commit scope defined and each release notice in alphabetical order.
----
Common Squash Commit Evaluation¶
Introduced in v9.17.0
All of the PSR built-in parsers implement common squash commit evaluation logic to identify and extract individual commit messages from a single squashed commit. The parsers will look for common squash commit delimiters and multiple matches of the commit message format to identify each individual commit message that was squashed. The parsers will return a list containing each commit message as a separate commit object. Squashed commits will be evaluated individually for both the level bump and changelog generation. If no squash commits are found, a list with the single commit object will be returned.
Currently, PSR has been tested against GitHub, BitBucket, and official git squash merge commit messages. GitLab does not have a default template for squash commit messages but can be customized per project or server. If you are using GitLab, you will need to ensure that the squash commit message format is similar to the example below.
Example:
The following example will extract three separate commit messages from a single GitHub formatted squash commit message of conventional commit style:
feat(config): add new config option (#123) * refactor(config): change the implementation of config loading * docs(configuration): defined new config option for the project
When parsed with the default conventional-commit parser with squash commits toggled on, the version bump will be determined by the highest level bump of the three commits (in this case, a minor bump because of the feature commit) and the release notes would look similar to the following:
## Features - **config**: add new config option (#123) ## Documentation - **configuration**: defined new config option for the project (#123) ## Refactoring - **config**: change the implementation of config loading (#123)
Merge request numbers and commit hash values will be the same across all extracted commits. Additionally, any exclude_commit_patterns will be applied individually to each extracted commit so if you are have an exclusion match for ignoring refactor commits, the second commit in the example above would be excluded from the changelog.
IMPORTANT:
----
Customization¶
Each of the built-in parsers can be customized by providing overrides in the commit_parser_options setting of the configuration file. This can be used to toggle parsing features on and off or to add, modify, or remove the commit types that are used to determine the level bump for a commit. Review the API documentation for the specific parser's options class to see what changes to the default behavior can be made.
----
Custom Parsers¶
Custom parsers can be written to handle commit message styles that are not covered by the built-in parsers or by option customization of the built-in parsers.
Python Semantic Release provides several building blocks to help you write your parser. To maintain compatibility with how Python Semantic Release will invoke your parser, you should use the appropriate object as described below, or create your own object as a subclass of the original which maintains the same interface. Type parameters are defined where appropriate to assist with static type-checking.
The commit_parser option, if set to a string which does not match one of Python Semantic Release's built-in commit parsers, will be used to attempt to dynamically import a custom commit parser class.
In order to use your custom parser, you must provide how to import the module and class via the configuration option. There are two ways to provide the import string:
- 1.
- File Path & Class: The format is "path/to/module_file.py:ClassName". This is the easiest way to provide a custom parser. This method allows you to store your custom parser directly in the repository with no additional installation steps. PSR will locate the file, load the module, and instantiate the class. Relative paths are recommended and it should be provided relative to the current working directory. This import variant is available in v9.16.0 and later.
- 2.
- Module Path & Class: The format is
"package.module_name:ClassName". This method allows you
to store your custom parser in a package that is installed in the same
environment as PSR. This method is useful if you want to share your custom
parser across multiple repositories. To share it across multiple
repositories generally you will need to publish the parser as its own
separate package and then pip install it into the current virtual
environment. You can also keep it in the same repository as your project
as long as it is in the current directory of the virtual environment and
is locatable by the Python import system. You may need to set the
PYTHONPATH environment variable if you have a more complex
directory structure. This import variant is available in v8.0.0 and later.
To test that your custom parser is importable, you can run the following command in the directory where PSR will be executed:
python -c "from package.module_name import ClassName"
NOTE:
Tokens¶
The tokens built into Python Semantic Release's commit parsing mechanism are inspired by both the error-handling mechanism in Rust's error handling and its implementation in black. It is documented that catching exceptions in Python is slower than the equivalent guard implemented using if/else checking when exceptions are actually caught, so although try/except blocks are cheap if no exception is raised, commit parsers should always return an object such as ParseError instead of raising an error immediately. This is to avoid catching a potentially large number of parsing errors being caught as the commit history of a repository is being parsed. Python Semantic Release does not raise an exception if a commit cannot be parsed.
Python Semantic Release uses ParsedCommit as the return type of a successful parse operation, and ParseError as the return type from an unsuccessful parse of a commit. You should review the API documentation linked to understand the fields available on each of these objects.
It is important to note, the ParseError implements an additional method, raise_error. This method raises a CommitParseError with the message contained in the error field, as a convenience.
In Python Semantic Release, the type semantic_release.commit_parser.token.ParseResult is defined as ParseResultType[ParsedCommit, ParseError], as a convenient shorthand.
ParseResultType is a generic type, which is the Union of its two type parameters. One of the types in this union should be the type returned on a successful parse of the commit, while the other should be the type returned on an unsuccessful parse of the commit.
A custom parser result type, therefore, could be implemented as follows:
- MyParsedCommit subclasses ParsedCommit
- MyParseError subclasses ParseError
- MyParseResult = ParseResultType[MyParsedCommit, MyParseError]
Internally, Python Semantic Release uses isinstance() to determine if the result of parsing a commit was a success or not, so you should check that your custom result and error types return True from isinstance(<object>, ParsedCommit) and isinstance(<object>, ParseError) respectively.
While it's not advisable to remove any of the fields that are available in the built-in token types, currently only the bump field of the successful result type is used to determine how the version should be incremented as part of this release. However, it's perfectly possible to add additional fields to your tokens which can be populated by your parser; these fields will then be available on each commit in your changelog template, so you can make additional information available.
Parser Options¶
When writing your own parser, you should accompany the parser with an "options" class which accepts the appropriate keyword arguments. This class' __init__ method should store the values that are needed for parsing appropriately. Python Semantic Release will pass any configuration options from the configuration file's commit_parser_options, into your custom parser options class. To ensure that the configuration options are passed correctly, the options class should inherit from the ParserOptions class.
The "options" class is used to validate the options which are configured in the repository, and to provide default values for these options where appropriate.
Commit Parsers¶
The commit parsers that are built into Python Semantic Release implement an instance method called parse, which takes a single parameter commit of type git.objects.commit.Commit, and returns the type ParseResultType.
To be compatible with Python Semantic Release, a commit parser must subclass CommitParser. A subclass must implement the following:
- A class-level attribute parser_options, which must be set to ParserOptions or a subclass of this.
- An __init__ method which takes a single parameter, options, that should be of the same type as the class' parser_options attribute.
- A method, parse, which takes a single parameter commit that is of type git.objects.commit.Commit, and returns ParseResult, or a subclass of this.
By default, the constructor for CommitParser will set the options parameter on the options attribute of the parser, so there is no need to override this in order to access self.options during the parse method. However, if you have any parsing logic that needs to be done only once, it may be a good idea to perform this logic during parser instantiation rather than inside the parse method. The parse method will be called once per commit in the repository's history during parsing, so the effect of slow parsing logic within the parse method will be magnified significantly for projects with sizeable Git histories.
Commit Parsers have two type parameters, "TokenType" and "OptionsType". The first is the type which is returned by the parse method, and the second is the type of the "options" class for this parser.
Therefore, a custom commit parser could be implemented via:
class MyParserOptions(semantic_release.ParserOptions):
def __init__(self, message_prefix: str) -> None:
self.prefix = message_prefix * 2 class MyCommitParser(
semantic_release.CommitParser[semantic_release.ParseResult, MyParserOptions] ):
def parse(self, commit: git.objects.commit.Commit) -> semantic_release.ParseResult:
...
Version Change Reports¶
When using the cmd-version and cmd-changelog commands, Python Semantic Release (PSR) will generate a changelog and release notes for your project automatically in the default configuration. The changelog is rendered using the Jinja template engine, and in the default configuration, PSR will use a built-in template file to render the changelog at the file location defined by the changelog_file setting.
Through the use of the templating engine & the template_dir configuration setting, you can customize the appearance of your changelog and release notes content. You may also generate a set of files using your custom template directory and the templates will be rendered relative to the root of your repository.
Because PSR uses a third-party library, Jinja, as its template engine, we do not include all the syntax within our documentation but rather you should refer to the Template Designer Documentation for guidance on how to customize the appearance of your release files. If you would like to customize the template environment itself, then certain options are available to you via changelog environment configuration.
If you do not want to use the changelog generation features, you can disable changelog generation entirely during the cmd-version command by providing the --no-changelog command-line option.
Using the Default Changelog¶
If you don't provide any custom templates in the changelog.template_dir, the default changelog templates will be used to render the changelog.
PSR provides two default changelog output formats:
- 1.
- Markdown (.md), default
- 2.
- reStructuredText (.rst), available since v9.11.0
Both formats are kept in sync with one another to display the equivalent information in the respective format. The default changelog template is located in the data/templates/ directory within the PSR package. The templates are written in modular style (ie. multiple files) and during the render process are ultimately combined together to render the final changelog output. The rendering start point is the CHANGELOG.{FORMAT_EXT}.j2 underneath the respective format directory.
PSR provides a few configuration options to customize the default changelog output and can be found under the changelog.default_templates section as well as some common configuration options under the changelog section.
To toggle the output format, you only need to set the changelog.default_templates.changelog_file file name to include the desired file extension (.md or .rst). If you would like a different extension for the resulting changelog file, but would like to still have control over the template format, you can set the changelog.default_templates.output_format configuration setting to the desired format.
A common and highly-recommended configuration option is the changelog.exclude_commit_patterns setting which allows the user to define regular expressions that will exclude commits from the changelog output. This is useful to filter out change messages that are not relevant to your external consumers (ex. ci and test in the conventional commit standard) and only include the important changes that impact the consumer of your software.
Another important configuration option is the changelog.mode setting which determines the behavior of the changelog generation. There are 2 modes that available that described in detail below.
- 1.
- Initialization Mode when mode = "init".
- 2.
- Update Mode when mode = "update".
Initialization Mode¶
When using the initialization mode, the changelog file will be created from scratch using the entire git history and overwrite any existing changelog file. This is the default behavior introduced in v8.0.0. This is useful when you are trying to convert over to Python Semantic Release for the first time or when you want to automatically update the entire format of your changelog file.
WARNING:
Please make sure to refer to Migrating an Existing Changelog.
Update Mode¶
NOTE:
When using the update mode, only the change information from the last release will be prepended into the existing changelog file (defined by the changelog.changelog_file). This mimics the behavior that was used in versions prior to v8.0.0 before the conversion to a templating engine but now uses the Jinja to accomplish the update. This mode is best suited for managing changes over the lifetime of your project when you may have a need to make manual changes or adjustments to the changelog and its not easily recreated with a template.
How It Works
In order to insert the new release information into an existing changelog file, your changelog file must have an insertion flag to indicate where the new release information should be inserted. The default template will read in your existing changelog file, split the content based on the insertion flag, and then recombine the content (including the insertion flag) with the new release information added after the insertion flag.
The insertion flag is customizable through the changelog.insertion_flag setting. Generally, your insertion flag should be unique text to your changelog file to avoid any unexpected behavior. See the examples below.
In the case where the insertion flag is NOT found in the existing changelog file, the changelog file will be re-written without any changes.
If there is no existing changelog file found, then the changelog file will be initialized from scratch as if the mode was set to init, except the changelog.insertion_flag will be included into the newly created changelog file.
TIP:
SEE ALSO:
- •
- Migrating an Existing Changelog.
Example
Given your existing changelog looks like the following with a changelog.insertion_flag set to <!-- version list -->, when you run the cmd-version command, the new release information will be inserted after the insertion flag.
Before
# CHANGELOG <!-- version list --> ## 1.0.0 - Initial Release
After
# CHANGELOG <!-- version list --> ## v1.1.0 ### Feature - feat: added a new feature ### Fix - fix: resolved divide by zero error ## 1.0.0 - Initial Release
Configuration Examples¶
- 1.
- Goal: Configure an updating reStructuredText changelog with a custom insertion flag within pyproject.toml.
[tool.semantic_release.changelog] mode = "update" insertion_flag = "..\n All versions below are listed in reverse chronological order" [tool.semantic_release.changelog.default_templates] changelog_file = "CHANGELOG.rst" output_format = "rst" # optional because of the file extension
- 2.
- Goal: Configure an updating Markdown changelog with custom file name and default insertion flag within a separate config file releaserc.json.
{
"semantic_release": {
"changelog": {
"mode": "update",
"default_templates": {
"changelog_file": "docs/HISTORY",
"output_format": "md"
}
}
}
}
- 3.
- Goal: Configure an initializing reStructuredText changelog with filtered conventional commits patterns and merge commits within a custom config file releaserc.toml.
[semantic_release.changelog]
mode = "init"
default_templates = { changelog_file = "docs/CHANGELOG.rst" }
exclude_commit_patterns = [
'''chore(?:\([^)]*?\))?: .+''',
'''ci(?:\([^)]*?\))?: .+''',
'''refactor(?:\([^)]*?\))?: .+''',
'''style(?:\([^)]*?\))?: .+''',
'''test(?:\([^)]*?\))?: .+''',
'''build\((?!deps\): .+)''',
'''Merged? .*''',
]
If identified or supported by the parser, the default changelog templates will include a separate section of breaking changes and additional release information. Refer to the commit parsing section to see how to write commit messages that will be properly parsed and displayed in these sections.
Using the Default Release Notes¶
PSR has the capability to generate release notes as part of the publishing of a new version similar to the changelog. The release notes are generated using a Jinja template and posted to the your remote version control server (VCS) such as GitHub, GitLab, etc during the cmd-version command. PSR provides a default built-in template out-of-the-box for generating release notes.
The difference between the changelog and release notes is that the release notes only contain the changes for the current release. Due to the modularity of the PSR templates, the format is similar to an individual version of the default changelog but may include other version specific information.
At this time, the default template for version release notes is only available in Markdown format for all VCS types.
If you want to review what the default release notes look like you can use the following command to print the release notes to the console (remove any configuration for defining a custom template directory):
# Create a current tag git tag v1.0.0 semantic-release --noop changelog --post-to-release-tag v1.0.0
The default template provided by PSR will respect the mask_initial_release setting and will also add a comparison link to the previous release if one exists without customization.
As of v9.18.0, the default release notes will also include a statement to declare which license the project was released under. PSR determines which license to declare based on the value of project.license-expression in the pyproject.toml file as defined in the PEP 639 specification.
SEE ALSO:
- •
- To personalize your release notes, see the Custom Release Notes section.
Custom Changelogs¶
If you would like to customize the appearance of your changelog, you can create your own custom templates and configure PSR to render your templates instead during the cmd-version and cmd-changelog commands.
To use a custom template, you need to create a directory within your repository and set the template_dir setting to the name of this directory. The default name is "templates".
Templates are identified by giving a .j2 extension to the template file. Any such templates have the .j2 extension removed from the target file. Therefore, to render an output file foo.csv, you should create a template called foo.csv.j2 within your template directory.
If you have additional files that you would like to render alongside your changelog, you can place these files within the template directory. A file within your template directory which does not end in .j2 will not be treated as a template; it will be copied to its target location without being rendered by the template engine.
TIP:
TIP:
Directory Structure¶
When the templates are rendered, files within the templates directory tree are output to the location within your repository that has the same relative path to the root of your project as the relative path of the template within the templates directory.
Example
An example project has the following structure:
example-project/ ├── src/ │ └── example_project/ │ └── __init__.py └── ch-templates/
├── CHANGELOG.md.j2
├── .components/
│ └── authors.md.j2
├── .macros.j2
├── src/
│ └── example_project/
│ └── data/
│ └── data.json.j2
└── static/
└── config.cfg
And a custom templates folder configured via the following snippet in pyproject.toml:
[tool.semantic_release.changelog] template_dir = "ch-templates"
After running a release with Python Semantic Release, the directory structure of the project will now look like this (excluding the template directory):
example-project/ ├── CHANGELOG.md ├── src/ │ └── example_project/ │ ├── data/ │ │ └── data.json │ └── __init__.py └── static/
└── config.cfg
Importantly, note the following:
- There is no top-level .macros file created, because hidden files are excluded from the rendering process.
- There is no top-level .components directory created, because hidden folders and all files and folders contained within it are excluded from the rendering process.
- The .components/authors.md.j2 file is not rendered directly, however, it is used as a component to the CHANGELOG.md.j2 via an include statement in the changelog template.
- To render data files into the src/ folder, the path to which the template should be rendered has to be created within the ch-templates directory.
- The ch-templates/static folder is created at the top-level of the project, and the file ch-templates/static/config.cfg is copied, not rendered to the new top-level static folder.
You may wish to leverage this behavior to modularize your changelog template, to define macros in a separate file, or to reference static data which you would like to avoid duplicating between your template environment and the remainder of your project.
Changelog Template Context¶
During the rendering of a directory tree, Python Semantic Release provides information about the history of the project available within the templating environment in order for it to be used to generate the changelog and other desired documents.
Important project information is provided to the templating environment through the global variable context or ctx for short. Within the template environment, the context object has the following attributes:
- •
- changelog_insertion_flag (str): the insertion flag used to
determine where the new release information should be inserted into the
changelog file. This value is passed directly from
changelog.insertion_flag.
Introduced in v9.10.0.
Example Usage:
{% set changelog_parts = prev_changelog_contents.split(
ctx.changelog_insertion_flag, maxsplit=1
)
%}
- •
- changelog_mode (Literal["init", "update"]): the
mode of the changelog generation currently being used. This can be used to
determine different rendering logic. This value is passed directly from
the changelog.mode configuration setting.
Introduced in v9.10.0.
Example Usage:
{% if ctx.changelog_mode == "init"
%}{% include ".changelog_init.md.j2"
%}{#
#}{% elif ctx.changelog_mode == "update"
%}{% include ".changelog_update.md.j2"
%}{#
#}{% endif
%}
- •
- history (ReleaseHistory): the ReleaseHistory instance for
the project (See the Release History section for more information).
Example Usage:
{% set unreleased_commits = ctx.history.unreleased | dictsort
%}{% for release in context.history.released.values()
%}{% include ".versioned_changes.md.j2"
#}{% endfor
%}
- •
- hvcs_type (str): the name of the VCS server type currently
configured. This can be used to determine which filters are available or
different rendering logic.
Introduced in v9.6.0.
Example Usage:
{% if ctx.hvcs_type == "github"
%}{{ "29" | pull_request_url
}}{#
#}{% elif ctx.hvcs_type == "gitlab"
%}{{ "29" | merge_request_url
}}{#
#}{% endif
%}
- •
- mask_initial_release (bool): a boolean value indicating whether the
initial release should be masked with a generic message. This value is
passed directly from the
changelog.default_templates.mask_initial_release configuration
setting.
Introduced in v9.14.0.
Example Usage:
#}{% if releases | length == 1 and ctx.mask_initial_release
%}{# # On a first release, generate a generic message
#}{% include ".components/first_release.md.j2"
%}{% else
%}{# # Not the first release
#}{% include ".components/versioned_changes.md.j2"
%}{% endif
%}
- •
- repo_name (str): the name of the current repository parsed from the
Git url.
Example Usage:
{{ ctx.repo_name }}
example_repo
- •
- repo_owner (str): the owner of the current repository parsed from
the Git url.
Example Usage:
{{ ctx.repo_owner }}
example_org
- •
- prev_changelog_file (str): the path to the previous changelog file
that should be updated with the new release information. This value is
passed directly from changelog.changelog_file.
Introduced in v9.10.0.
Example Usage:
{% set prev_changelog_contents = prev_changelog_file | read_file | safe %}
Release History¶
A ReleaseHistory object has two attributes: released and unreleased.
The unreleased attribute is of type Dict[str, List[ParseResult]]. Each commit in the current branch's commit history since the last release on this branch is grouped by the type attribute of the ParsedCommit returned by the commit parser, or if the parser returned a ParseError then the result is grouped under the "unknown" key.
For this reason, every element of ReleaseHistory.unreleased["unknown"] is a ParseError, and every element of every other value in ReleaseHistory.unreleased is of type ParsedCommit.
Typically, commit types will be "feature", "fix", "breaking", though the specific types are determined by the parser. For example, the EmojiCommitParser uses a textual representation of the emoji corresponding to the most significant change introduced in a commit (e.g. ":boom:") as the different commit types. As a template author, you are free to customize how these are presented in the rendered template.
NOTE:
The released attribute is of type Dict[Version, Release]. The keys of this dictionary correspond to each version released within this branch's history, and are of type Version. You can use the as_tag() method to render these as the Git tag that they correspond to inside your template.
A Release object has an elements attribute, which has the same structure as the unreleased attribute of a ReleaseHistory; that is, elements is of type Dict[str, List[ParseResult]], where every element of elements["unknown"] is a ParseError, and elements of every other value correspond to the type attribute of the ParsedCommit returned by the commit parser.
The commits represented within each ReleaseHistory.released[version].elements grouping are the commits which were made between version and the release corresponding to the previous version. That is, given two releases Version(1, 0, 0) and Version(1, 1, 0), ReleaseHistory.released[Version(1, 0, 0)].elements contains only commits made after the release of Version(1, 0, 0) up to and including the release of Version(1, 1, 0).
To maintain a consistent order of subsections in the changelog headed by the commit type, it's recommended to use Jinja's dictsort filter.
Each Release object also has the following attributes:
- tagger: git.Actor: The tagger who tagged the release.
- committer: git.Actor: The committer who made the release commit.
- tagged_date: datetime: The date and time at which the release was tagged.
SEE ALSO:
- Built-in Commit Parsers
- Commit Parser Tokens
- git.Actor
- datetime.strftime Format Codes
Changelog Template Filters¶
In addition to the context variables, PSR seeds the template environment with a set of custom functions (commonly called filters in Jinja terminology) for use within the template. Filter's first argument is always piped (|) to the function while any additional arguments are passed in parentheses like normal function calls.
The filters provided vary based on the VCS configured and available features:
- •
- autofit_text_width (Callable[[textStr, maxWidthInt, indent_sizeInt],
textStr]): given a text string, fit the text to the maximum width
provided. This filter is useful when you want to wrap text to a specific
width. The filter will attempt to break the text at word boundaries and
will indent the text by the amount specified in the indent_size
parameter.
Introduced in v9.12.0.
Example Usage:
{{ "This is a long string that needs to be wrapped to a specific width" | autofit_text_width(40, 4) }}
Markdown Output:
This is a long string that needs to be
wrapped to a specific width
- •
- convert_md_to_rst (Callable[[MdStr], RstStr]): given a markdown
string, convert it to reStructuredText format. This filter is useful when
building a reStructuredText changelog but your commit messages are in
markdown format. It is utilized by the default RST changelog template. It
is limited in its ability to convert all markdown to reStructuredText, but
it handles most common cases (bold, italics, inline-raw, etc.) within
commit messages.
Introduced in v9.11.0.
Example Usage:
{{ "\n* %s (`%s`_)\n" | format(
commit.message.rstrip() | convert_md_to_rst,
commit.short_hash,
)
}}
- •
- create_pypi_url(package_name: str, version: str = ""):
given a package name and an optional version, return a URL to the PyPI
page for the package. If a version is provided, the URL will point to the
specific version page. If no version is provided, the URL will point to
the package page.
Introduced in v9.18.0.
Example Usage:
{{ "example-package" | create_pypi_url }}
{{ "example-package" | create_pypi_url("1.0.0") }}
Markdown Output:
- •
- create_release_url (Callable[[TagStr], UrlStr]): given a tag,
return a URL to the release page on the remote vcs. This filter is useful
when you want to link to the release page on the remote vcs.
Introduced in v9.18.0.
Example Usage:
{{ "v1.0.0" | create_release_url }}
Markdown Output:
- •
- create_server_url (Callable[[PathStr, AuthStr | None, QueryStr | None,
FragmentStr | None], UrlStr]): when given a path, prepend the
configured vcs server host and url scheme. Optionally you can provide, a
auth string, a query string or a url fragment to be normalized into the
resulting url. Parameter order is as described above respectively.
Introduced in v9.6.0.
Example Usage:
{{ "example/repo.git" | create_server_url }}
{{ "example/repo" | create_server_url(None, "results=1", "section-header") }}
Markdown Output:
- •
- create_repo_url (Callable[[RepoPathStr, QueryStr | None, FragmentStr |
None], UrlStr]): when given a repository path, prepend the configured
vcs server host, and repo namespace. Optionally you can provide, an
additional query string and/or a url fragment to also put in the url.
Parameter order is as described above respectively. This is similar to
create_server_url but includes the repo namespace and owner
automatically.
Introduced in v9.6.0.
Example Usage:
{{ "releases/tags/v1.0.0" | create_repo_url }}
{{ "issues" | create_repo_url("q=is%3Aissue+is%3Aclosed") }}
Markdown Output:
https://example.com/example/repo/releases/tags/v1.0.0 https://example.com/example/repo/issues?q=is%3Aissue+is%3Aclosed
- •
- commit_hash_url (Callable[[hashStr], UrlStr]): given a commit hash,
return a URL to the commit in the remote.
Introduced in v8.0.0.
Example Usage:
{{ commit.hexsha | commit_hash_url }}
Markdown Output:
- •
- compare_url (Callable[[StartRefStr, StopRefStr], UrlStr]): given a
starting git reference and a ending git reference create a comparison url
between the two references that can be opened on the remote
Introduced in v9.6.0.
Example Usage:
{{ "v1.0.0" | compare_url("v1.1.0") }}
Markdown Output:
- •
- issue_url (Callable[[IssueNumStr | IssueNumInt], UrlStr]): given an
issue number, return a URL to the issue on the remote vcs. In v9.12.2,
this filter was updated to handle a string that has leading prefix symbols
(ex. #32) and will strip the prefix before generating the URL.
Introduced in v9.6.0, Modified in v9.12.2.
Example Usage:
{# Add Links to issues annotated in the commit message
# NOTE: commit.linked_issues is only available in v9.15.0 or greater
#
#}{% for issue_ref in commit.linked_issues
%}{{ "- [%s](%s)" | format(issue_ref, issue_ref | issue_url)
}}{% endfor
%}
Markdown Output:
- •
- merge_request_url (Callable[[MergeReqStr | MergeReqInt], UrlStr]):
given a merge request number, return a URL to the merge request in the
remote. This is an alias to the pull_request_url but only available
for the VCS that uses the merge request terminology. In v9.12.2, this
filter was updated to handle a string that has leading prefix symbols (ex.
#29) and will strip the prefix before generating the URL.
Introduced in v9.6.0, Modified in v9.12.2.
Example Usage:
{{
"[%s](%s)" | format(
commit.linked_merge_request,
commit.linked_merge_request | merge_request_url
)
}}
{# commit.linked_merge_request is only available in v9.13.0 or greater #}
Markdown Output:
- •
- pull_request_url (Callable[[PullReqStr | PullReqInt], UrlStr]):
given a pull request number, return a URL to the pull request in the
remote. For remote vcs' that use merge request terminology, this filter is
an alias to the merge_request_url filter function. In v9.12.2, this
filter was updated to handle a string that has leading prefix symbols (ex.
#29) and will strip the prefix before generating the URL.
Introduced in v9.6.0, Modified in v9.12.2.
Example Usage:
{# Create a link to the merge request associated with the commit
# NOTE: commit.linked_merge_request is only available in v9.13.0 or greater
#}{{
"[%s](%s)" | format(
commit.linked_merge_request,
commit.linked_merge_request | pull_request_url
)
}}
Markdown Output:
- •
- format_w_official_vcs_name (Callable[[str], str]): given a format
string, insert the official VCS type name into the string and return. This
filter is useful when you want to display the proper name of the VCS type
in a changelog or release notes. The filter supports three different
replace formats: %s, {}, and {vcs_name}.
Introduced in v9.18.0.
Example Usage:
{{ "%s Releases" | format_w_official_vcs_name }}
{{ "{} Releases" | format_w_official_vcs_name }}
{{ "{vcs_name} Releases" | format_w_official_vcs_name }}
Markdown Output:
GitHub Releases GitHub Releases GitHub Releases
- •
- read_file (Callable[[str], str]): given a file path, read the file
and return the contents as a string. This function was added specifically
to enable the changelog update feature where it would load the existing
changelog file into the templating environment to be updated.
Introduced in v9.10.0.
Example Usage:
{% set prev_changelog_contents = prev_changelog_file | read_file | safe %}
- •
- sort_numerically (Callable[[Iterable[str], bool], list[str]]):
given a sequence of strings with possibly some non-number characters as a
prefix or suffix, sort the strings as if they were just numbers from
lowest to highest. This filter is useful when you want to sort issue
numbers or other strings that have a numeric component in them but cannot
be cast to a number directly to sort them. If you want to sort the strings
in reverse order, you can pass a boolean value of True as the
second argument.
Introduced in v9.16.0.
Example Usage:
{{ ["#222", "#1023", "#444"] | sort_numerically }}
{{ ["#222", "#1023", "#444"] | sort_numerically(True) }}
Markdown Output:
['#222', '#444', '#1023'] ['#1023', '#444', '#222']
Availability of the documented filters can be found in the table below:
| filter - hvcs_type | bitbucket | gitea | github | gitlab |
| autofit_text_width | ✅ | ✅ | ✅ | ✅ |
| convert_md_to_rst | ✅ | ✅ | ✅ | ✅ |
| create_pypi_url | ✅ | ✅ | ✅ | ✅ |
| create_server_url | ✅ | ✅ | ✅ | ✅ |
| create_release_url | ❌ | ✅ | ✅ | ✅ |
| create_repo_url | ✅ | ✅ | ✅ | ✅ |
| commit_hash_url | ✅ | ✅ | ✅ | ✅ |
| compare_url | ✅ | ❌ | ✅ | ✅ |
| format_w_official_vcs_name | ✅ | ✅ | ✅ | ✅ |
| issue_url | ❌ | ✅ | ✅ | ✅ |
| merge_request_url | ❌ | ❌ | ❌ | ✅ |
| pull_request_url | ✅ | ✅ | ✅ | ✅ |
| read_file | ✅ | ✅ | ✅ | ✅ |
| sort_numerically | ✅ | ✅ | ✅ | ✅ |
SEE ALSO:
- •
- Filters
Example¶
The following template is a simple example of how to render a changelog using the PSR template context to create a changelog in Markdown format.
Configuration: pyproject.toml
[tool.semantic_release.changelog] template_dir = "templates"
Template: templates/CHANGELOG.md.j2
# CHANGELOG
{% for version, release in ctx.history.released.items()
%}{{
"## %s (%s)" | format(version.as_tag(), release.tagged_date.strftime("%Y-%m-%d"))
}}{% for type_, commits in release["elements"] if type_ != "unknown" | dictsort
%}{{
"### %s" | format(type_ | title)
}}{% for commit in commits
%}{{
"* %s ([`%s`](%s))" | format(
commit.descriptions[0] | capitalize,
commit.hexsha[:7],
commit.hexsha | commit_hash_url,
)
}}{% endfor
%}{% endfor
%}{% endfor
%}
Result: CHANGELOG.md
# CHANGELOG ## v1.1.0 (2022-01-01) ### Feature * Added a new feature ([`a1b2c3d`](https://github.com/example/repo/commit/a1b2c3d)) ## v1.0.0 (2021-12-31) ### Fix * Resolved divide by zero error ([`e4f5g6h`](https://github.com/example/repo/commit/e4f5g6h))
It is important to note that the template utilizes the context variable to extract the project history as well as the commit_hash_url filter to generate a URL to the remote VCS for each commit. Both of these are injected into the template environment by PSR.
Custom Release Notes¶
If you would like to customize the appearance of your release notes, you can add a hidden file named .release_notes.md.j2 at the root of your changelog.template_dir. This file will automatically be detected and used to render the release notes during the cmd-version and cmd-changelog commands.
A similar template rendering mechanism is used to render the release notes as is used for the changelog. There are minor differences in the context available to the release notes template but the template directory structure and modularity is maintained.
TIP:
Release Notes Context¶
All of the changelog's template context is exposed to the Jinja template when rendering the release notes.
Additionally, the following two globals are available to the template:
- release (Release): contains metadata about the content of
the release, as parsed from commit logs
Introduced in v8.0.0.
- version (Version): contains metadata about the software
version to be released and its git tag
Introduced in v8.0.0.
Example¶
Below is an example template that can be used to render release notes (it's similar to GitHub's automatically generated release notes):
Configuration: pyproject.toml
[tool.semantic_release.changelog] template_dir = "templates"
Template: templates/.release_notes.md.j2
## What's Changed
{% for type_, commits in release["elements"] | dictsort
%}{%- if type_ != "unknown"
%}{{
"### %s" | format(type_ | title)
}}{% for commit in commits
%}{{
"* %s by %s in [`%s`](%s)" | format(
commit.descriptions[0] | capitalize,
commit.commit.author.name,
commit.hexsha[:7],
commit.hexsha | commit_hash_url,
)
}}{%- endfor
%}{% endif
%}{% endfor
%}
Result: https://github.com/example/repo/releases/tag/v1.1.0
## What's Changed ### Feature * Added a new feature by John Doe in [`a1b2c3d`](https://github.com/example/repo/commit/a1b2c3d)
Migrating an Existing Changelog¶
v9.10.0 or greater
Migrating an existing changelog is simple with Python Semantic Release! To preserve your existing changelog, follow these steps:
- 1.
- Set the changelog.mode to "update" in your configuration file. This will ensure that only the new release information is added to your existing changelog file.
- 2.
- Set the changelog.insertion_flag to a unique string. You may use the default value or set it to a unique string that is not present in your existing changelog file. This flag is used to determine where the new release information should be inserted into your existing changelog.
- 3.
- Add the insertion flag to your changelog file. This must match the value you set in step 2. The insertion flag should be placed in the location above where you would like the new release information to be inserted.
NOTE:
Prior to v9.10.0
If you have an existing changelog that you would like to preserve, you will need to add the contents of the changelog file to your changelog template - either directly or via Jinja's include tag.
If you would like only the history from your next release onwards to be rendered into the changelog in addition to the existing changelog, you can add an if statement based upon the versions in the keys of context.released.
Upgrading Templates¶
As PSR evolves, new features and improvements are added to the templating engine. If you have created your own custom templates, you may need to update them to take advantage of some new features. Below are some instructions on how to upgrade your templates to gain the benefits of the new features.
Incrementally Updating Changelog Template¶
NOTE:
If you have previously created your own custom templates and would like to gain the benefits of the new updating changelog feature, you will need to make a few changes to your existing templates.
The following steps are a few suggestions to help upgrade your templates but primarily you should review the embedded default templates in the PSR package for a full example. You can find the default templates at data/templates/ directory.
- 1.
- Add a conditional to check the changelog_mode. This will allow you to determine if you should render the entire changelog or just the new release information. See data/templates/*/md/CHANGELOG.md.j2 for reference.
- 2.
- Use the new read_file filter to read in the existing changelog file ctx.prev_changelog_file. This will allow you to include the existing changelog content in your new changelog file. See data/templates/*/md/.components/changelog_update.md.j2 for reference.
- 3.
- Split the changelog content based on the insertion flag. This will allow you to insert the new release information after the insertion flag (ctx.changelog_insertion_flag). See data/templates/*/md/.components/changelog_update.md.j2 for reference.
- 4.
- Print the leading content before the insertion flag. This ensures you maintain any content that should be included before the new release information. See data/templates/*/md/.components/changelog_update.md.j2 for reference.
- 5.
- Print your insertion flag. This is imperative to ensure that the resulting changelog can be updated in the future. See data/templates/*/md/.components/changelog_update.md.j2 for reference.
- 6.
- Print the new release information. Be sure to consider both unreleased and released commits during this step because of the cmd-changelog command that can be run at any time. See data/templates/*/md/.components/changelog_update.md.j2 for reference.
- 7.
- Print the trailing content after the insertion flag. This ensures you maintain any content that should be included after the new release information. See data/templates/*/md/.components/changelog_update.md.j2 for reference.
TIP:
TIP:
Multibranch Releases¶
Python Semantic Release supports releases from multiple branches within your Git repository. You can elect to have a branch or set of branches create releases or prereleases. There are no restrictions enforced on how you set up your releases, but be aware that if you create new releases from multiple branches, or prereleases from multiple independent branches using the same prerelease token, there is a chance that Python Semantic Release will calculate the next version to be the same on more than one branch (leading to an error that a Git tag already exists).
NOTE:
Typical strings used for pre-release tokens include "alpha", "beta", "dev" and "rc". These tend to indicate a level of maturity of the software associated with the version, but the specific meaning of each string is up to the project to decide.
Generally, it's good practice to maintain a single branch from which full releases are made, and one branch at a time for each type of prerelease (alpha, beta, rc, etc).
If you absolutely require tagging and (pre-)releases to take place from multiple branches where there's a risk that tags could conflict between branches, you can use the --build-metadata command line argument to attach additional information (such as the branch name) to the tag in order to uniquely distinguish it from any other tags that might be calculated against other branches. Such a situation may occur in the following scenario:
O ----------- O <---- feature-1
/ "feat: abc"
/
O -------- O --------------- O <---- main v1.0.0 v1.1.0
\
O ----------- O <---- feature-2
"feat: 123"
Suppose that Python Semantic Release has been configured to use the same prerelease token "alpha" for all feature-* branches, and the default tag format "v{version}". In this case, running a pre-release from branch feature-1 will recognize that since the last release, 1.1.0, a feature has been introduced and therefore the next tag to be applied to feature-1 will be v1.2.0-alpha.1.
However, suppose we then try to run a release against feature-2. This will also recognize that a feature has been introduced against the last released version of v1.1.0 and therefore will try to create the tag v1.2.0-alpha.1, leading to an error as this tag was already created against feature-1.
To get around this issue, you can pass the branch name as part of the build metadata:
semantic-release version --build-metadata $(git branch --show-current)
This would lead to the tag v1.2.0-alpha.1+feature-1 and v1.2.0-alpha.1+feature-2 being applied to branches feature-1 and feature-2, respectively. Note that "build metadata MUST be ignored" per the semver specification when comparing two versions, so these two prereleases would be considered equivalent semantic versions, but when merged to the branch configured to produce full releases (main), if released separately the changes from each branch would be released in two versions that would be considered different according to the semver specification.
NOTE:
Configuring Multibranch Releases¶
Within your configuration file, you can create one or more groups of branches ("release groups") that produce a certain type of release. Options are configured at the group level, and the group to use is chosen based on the current branch name against which Python Semantic Release is running.
Each release group is configured as a nested mapping under the tool.semantic_release.branches key in pyproject.toml, or the equivalent structure in other formats. the mapping requires a single key that is used as a name for the release group, which can help to identify it in log messages but has no effect on the behavior of the release. For example, Python Semantic Release has only one release group by default with the name main.
Inside each release group, the following key-value pairs can be set:
| Key | Required | Default | Description |
| match | Yes | N/A | A Python regular expression to match against the active branch's name. If the branch name matches the provided regular expression, then this release group is chosen to provide the other configuration settings available. |
| prerelease | No | false | Whether or not branches in this release group should a prerelease instead of a full release |
| prerelease_token | No | rc | If creating a prerelease, specify the string to be used as a prerelease token in any new versions created against this branch. |
WARNING:
Because of this, it's recommended that you place release groups with more specific match patterns higher up in your configuration file than those with patterns that would match a broader range of branch names.
For example, suppose a project currently on version 1.22.4 is working on a new major version. The project wants to create a branch called 2.x.x against which they will develop the new major version, and they would like to create "release candidate" ("rc") prereleases from this branch. There are also a number of new features to integrate, and the project has agreed that all such branches should be named according to the convention next-{developer initials}-{issue number}, leading to branches named similarly to next-bc-prj-123. The project would like to release with tags that include some way to identify the branch and date on which the release was made from the tag.
This project would be able to leverage the following configuration to achieve the above requirements from their release configuration:
[tool.semantic_release.branches.main] match = "(main|master)" prerelease = false [tool.semantic_release.branches."2.x.x"] match = "2.x.x" prerelease = true prerelease_token = "rc" [tool.semantic_release.branches."2.x.x New Features"] match = "next-\\w+-prj-\\d+" prerelease = true prerelease_token = "alpha"
In a CI pipeline, the following command would allow attaching the date and branch name to the versions that are produced (note this example uses the UNIX date command):
semantic-release version \
--build-metadata "$(git branch --show-current).$(date +%Y%m%d)"
This would lead to versions such as 1.1.1+main.20221127 or 2.0.0-rc.4+2.x.x.20221201.
NOTE:
Strict Mode¶
Strict Mode is enabled by use of the strict parameter to the main command for Python Semantic Release. Strict Mode alters the behavior of Python Semantic Release when certain conditions are encountered that prevent Python Semantic Release from performing an action. Typically, this will result in a warning becoming an error, or a different exit code (0 vs non-zero) being produced when Python Semantic Release exits early.
For example:
#!/usr/bin/bash set -euo pipefail git checkout $NOT_A_RELEASE_BRANCH pip install \
black \
isort \
twine \
pytest \
python-semantic-release isort . # sort imports black . # format the code pytest # test the code semantic-release --strict version # ERROR - not a release branch twine upload dist/* # publish the code
Using Strict Mode with the --strict flag ensures this simple pipeline will fail while running semantic-release, as the non-zero exit code will cause it to stop when combined with the -e option.
Without Strict Mode, the semantic-release command will exit with code 0, causing the above pipeline to continue.
The specific effects of enabling Strict Mode are detailed below.
Non-Release Branches¶
When running in Strict Mode, invoking Python Semantic Release on a non-Release branch will cause an error with a non-zero exit code. This means that you can prevent an automated script from running further against branches you do not want to release from, for example in multibranch CI pipelines.
Running without Strict Mode will allow subsequent steps in the pipeline to also execute, but be aware that certain actions that Python Semantic Release may perform for you will likely not have been carried out, such as writing to files or creating a git commit in your repository.
SEE ALSO:
- •
- Multibranch Releases
Version Already Released/No Release To Be Made¶
When Strict Mode is not enabled and Python Semantic Release identifies that no release needs to be made, it will exit with code 0. You can cause Python Semantic Release to raise an error if no release needs to be made by enabling Strict Mode.
Configuration¶
Python Semantic Release is highly configurable, allowing you to tailor it to your project's needs. It supports various runtime environments and can be integrated with different CI/CD services.
- 1.
- Check out our set of configuration guides to help walk you through the set up of common project customizations.
- 2.
- Dive in deep and explore the full set of possible customization options.
- 3.
- Go Automatic and Configure your CI/CD services to use Python Semantic Release.
Configuration Guides¶
This section provides detailed guides on how to configure PSR for various use cases and integrations. It is recommended to complete the Getting Started Guide first before diving into these more specific configurations.
Releasing Packages from a Monorepo¶
A monorepo (mono-repository) is a software development strategy where code for multiple projects is stored in a single source control system. This approach streamlines and consolidates configuration, but introduces complexities when using automated tools like Python Semantic Release (PSR).
Previously, PSR offered limited compatibility with monorepos. As of v10.4.0, PSR introduces the Conventional Commits Monorepo Parser, designed specifically for monorepo environments. To fully leverage this new parser, you must configure your monorepo as described below.
Configuring PSR¶
Example: Simple¶
Directory Structure: PSR does not yet support a single, workspace-level configuration definition. This means each package in the monorepo requires its own PSR configuration file. A compatible and common monorepo file structure looks like:
project/ ├── .git/ ├── .venv/ ├── packages/ │ ├── pkg1/ │ │ ├── docs/ │ │ │ └── source/ │ │ │ ├── conf.py │ │ │ └── index.rst │ │ │ │ │ ├── src/ │ │ │ └── pkg1/ │ │ │ ├── __init__.py │ │ │ ├── __main__.py │ │ │ └── py.typed │ │ │ │ │ ├── CHANGELOG.md │ │ ├── README.md │ │ └── pyproject.toml <-- PSR Configuration for Package 1 │ │ │ └── pkg2/ │ ├── docs/ │ │ └── source/ │ │ ├── conf.py │ │ └── index.rst │ ├── src/ │ │ └── pkg2/ │ │ ├── __init__.py │ │ ├── __main__.py │ │ └── py.typed │ │ │ ├── CHANGELOG.md │ ├── README.md │ └── pyproject.toml <-- PSR Configuration for Package 2 │ ├── .gitignore └── README.md
This is the most basic monorepo structure, where each package is self-contained with its own configuration files, documentation, and CHANGELOG files. To release a package, change your current working directory to the package directory and execute PSR's cmd-version. PSR will automatically read the package's pyproject.toml, looking for the [tool.semantic_release] section to determine the package's versioning and release configuration, then search up the file tree to find the Git repository.
Because there is no workspace-level configuration, you must duplicate any common PSR configuration in each package's configuration file. Customize each configuration for each package to specify how PSR should distinguish between commits.
With the example file structure above, here is an example configuration file for each package:
# FILE: pkg1/pyproject.toml
[project]
name = "pkg1"
version = "1.0.0"
[tool.semantic_release]
commit_parser = "conventional-monorepo"
commit_message = """\
chore(release): pkg1@{version}`
Automatically generated by python-semantic-release
"""
tag_format = "pkg1-v{version}"
version_toml = ["pyproject.toml:project.version"]
[tool.semantic_release.commit_parser_options]
path_filters = ["."]
scope_prefix = "pkg1-"
# FILE: pkg2/pyproject.toml
[project]
name = "pkg2"
version = "1.0.0"
[tool.semantic_release]
commit_parser = "conventional-monorepo"
commit_message = """\
chore(release): pkg2@{version}`
Automatically generated by python-semantic-release
"""
tag_format = "pkg2-v{version}"
version_toml = ["pyproject.toml:project.version"]
[tool.semantic_release.commit_parser_options]
path_filters = ["."]
scope_prefix = "pkg2-"
These are the minimum configuration options required for each package. Note the use of tag_format to distinguish tags between packages. The commit parser options are specific to the new Conventional Commits Monorepo Parser and play a significant role in identifying which commits are relevant to each package. Since you are expected to change directories to each package before releasing, file paths in each configuration file should be relative to the package directory.
Each package also defines a slightly different commit_message to reflect the package name in each message. This helps clarify which release number is being updated in the commit history.
Release Steps¶
Given the following Git history of a monorepo using a GitHub Flow branching strategy (without CI/CD): [image]
To manually release both packages, run:
cd packages/pkg1 semantic-release version # 1.0.1 (tag: pkg1-v1.0.1) cd ../pkg2 semantic-release version # 1.1.0 (tag: pkg2-v1.1.0)
After releasing both packages, the resulting Git history will look like: [image]
SEE ALSO:
- •
- GitHub Actions with Monorepos
Considerations¶
- 1.
- Custom Changelogs: Managing changelogs can be tricky depending on where you want to write the changelog files. In this simple example, the changelog is located within each package directory, and the changelog template does not have any package-specific formatting or naming convention. You can use one shared template directory at the root of the project and configure each package to point to the shared template directory.
# FILE: pkg1/pyproject.toml [tool.semantic_release] template_dir = "../../config/release-templates"
# FILE: pkg2/pyproject.toml [tool.semantic_release] template_dir = "../../config/release-templates"
project/ ├── .git/ ├── config/ │ └── release-templates/ │ ├── CHANGELOG.md.j2 │ └── .release_notes.md.j2 ├── packages/ │ ├── pkg1/ │ │ ├── CHANGELOG.md │ │ └── pyproject.toml │ │ │ └── pkg2/ │ ├── CHANGELOG.md │ └── pyproject.toml │ ├── .gitignore └── README.md
SEE ALSO:
- •
- For situations with more complex documentation needs, see our Advanced Example.
- 2.
- Package Prereleases: Creating pre-releases is possible, but it is recommended to use package-prefixed branch names to avoid collisions between packages. For example, to enable alpha pre-releases for new features in both packages, use the following configuration:
# FILE: pkg1/pyproject.toml [tool.semantic_release.branches.alpha-release] match = "^pkg1/feat/.+" # <-- note pkg1 prefix prerelease = true prerelease_token = "alpha"
# FILE: pkg2/pyproject.toml [tool.semantic_release.branches.alpha-release] match = "^pkg2/feat/.+" # <-- note pkg2 prefix prerelease = true prerelease_token = "alpha"
----
Example: Advanced¶
If you want to consolidate documentation into a single top-level directory, the setup becomes more complex. In this example, there is a common documentation folder at the top level, and each package has its own subfolder within the documentation folder.
Due to naming conventions, PSR cannot automatically accomplish this with its default changelog templates. For this scenario, you must copy the internal PSR templates into a custom directory (even if you do not modify them) and add custom scripting to prepare for each release.
The directory structure looks like:
project/ ├── .git/ ├── docs/ │ ├── source/ │ │ ├── pkg1/ │ │ │ ├── changelog.md │ │ │ └── README.md │ │ ├── pkg2/ │ │ │ ├── changelog.md │ │ │ └── README.md │ │ └── index.rst │ │ │ └── templates/ │ ├── .base_changelog_template/ │ │ ├── components/ │ │ │ ├── changelog_header.md.j2 │ │ │ ├── changelog_init.md.j2 │ │ │ ├── changelog_update.md.j2 │ │ │ ├── changes.md.j2 │ │ │ ├── first_release.md.j2 │ │ │ ├── macros.md.j2 │ │ │ ├── unreleased_changes.md.j2 │ │ │ └── versioned_changes.md.j2 │ │ └── changelog.md.j2 │ ├── .gitignore │ └── .release_notes.md.j2 │ ├── packages/ │ ├── pkg1/ │ │ ├── src/ │ │ │ └── pkg1/ │ │ │ ├── __init__.py │ │ │ └── __main__.py │ │ └── pyproject.toml │ │ │ └── pkg2/ │ ├── src/ │ │ └── pkg2/ │ │ ├── __init__.py │ │ └── __main__.py │ └── pyproject.toml │ └── scripts/
├── release-pkg1.sh
└── release-pkg2.sh
Each package should point to the docs/templates/ directory to use a common release notes template. PSR ignores hidden files and directories when searching for template files to create, allowing you to hide shared templates in the directory for use in your release setup script.
Here is our configuration file for package 1 (package 2 is similarly defined):
# FILE: pkg1/pyproject.toml
[project]
name = "pkg1"
version = "1.0.0"
[tool.semantic_release]
commit_parser = "conventional-monorepo"
commit_message = """\
chore(release): Release `pkg1@{version}`
Automatically generated by python-semantic-release
"""
tag_format = "pkg1-v{version}"
version_toml = ["pyproject.toml:project.version"]
[tool.semantic_release.commit_parser_options]
path_filters = [
".",
"../../../docs/source/pkg1/**",
]
scope_prefix = "pkg1-"
[tool.semantic_release.changelog]
template_dir = "../../../docs/templates"
mode = "update"
exclude_commit_patterns = [
'''^chore(?:\([^)]*?\))?: .+''',
'''^ci(?:\([^)]*?\))?: .+''',
'''^refactor(?:\([^)]*?\))?: .+''',
'''^style(?:\([^)]*?\))?: .+''',
'''^test(?:\([^)]*?\))?: .+''',
'''^Initial [Cc]ommit''',
]
[tool.semantic_release.changelog.default_templates]
# To enable update mode: this value must set here because the default is not the
# same as the default in the other package & must be the final destination filename
# for the changelog relative to this file
changelog_file = "../../../docs/source/pkg1/changelog.md"
Note: In this configuration, we added path filters for additional documentation files related to the package so that the changelog will include documentation changes as well.
Next, define a release script to set up the common changelog templates in the correct directory format so PSR will create the desired files at the proper locations. Following the Custom Changelogs reference, you must define the folder structure from the root of the project within the templates directory so PSR will properly lay down the files across the repository. The script cleans up any previous templates, dynamically creates the necessary directories, and copies over the shared templates into a package-named directory. Now you are prepared to run PSR for a release of pkg1.
#!/bin/bash
# FILE: scripts/release-pkg1.sh
set -euo pipefail
PROJECT_ROOT="$(dirname "$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")")"
VIRTUAL_ENV="$PROJECT_ROOT/.venv"
PACKAGE_NAME="pkg1"
cd "$PROJECT_ROOT" || exit 1
# Setup documentation template
pushd "docs/templates" >/dev/null || exit 1
rm -rf docs/
mkdir -p "docs/source/"
cp -r .base_changelog_template/ "docs/source/$PACKAGE_NAME"
popd >/dev/null || exit 1
# Release the package
pushd "packages/$PACKAGE_NAME" >/dev/null || exit 1
printf '%s\n' "Releasing $PACKAGE_NAME..."
"$VIRTUAL_ENV/bin/semantic-release" -v version --no-push
popd >/dev/null || exit 1
That's it! This example demonstrates how to set up a monorepo with shared changelog templates and a consolidated documentation folder for multiple packages.
SEE ALSO:
- •
- Advanced Example Monorepo: codejedi365/psr-monorepo-poweralpha
Ultraviolet (uv) Integration¶
uv is an extremely fast Python package and project manager that provides a modern alternative to pip and venv. It provides a lot of features that solve the common problems of Python package management but it also introduces a few quirks that need to be taken into account when using Python Semantic Release.
IMPORTANT:
Updating the uv.lock¶
One of the best features of uv is that it automatically generates a lock file (uv.lock) that contains the exact versions of all the dependencies used in your project. The lock file is generated when you run the uv install command, and it is used to ensure that CI workflows are repeatable and development environments are consistent.
When creating a new release using Python Semantic Release, PSR will update the version in the project's definition file (e.g., pyproject.toml) to indicate the new version. Unfortunately, this action will cause uv to fail on the next execution because the lock file will be out of sync with the project's definition file. There are two ways to resolve this issue depending on your preference:
- 1.
- Add a step to your build command: Modify your semantic_release.build_command to include the command to update the lock file and stage it for commit. This is commonly used with the GitHub Action and other CI/CD tools when you are building the artifact at the time of release.
[tool.semantic_release] build_command = """
uv lock --upgrade-package "$PACKAGE_NAME"
git add uv.lock
uv build """
The intent of the lock upgrade-package call is ONLY to update the version of your project within the lock file after PSR has updated the version in your project's definition file (e.g., pyproject.toml). When you are running PSR, you have already tested the project as is and you don't want to actually update the dependencies if a new one just became available.
For ease of use, PSR provides the $PACKAGE_NAME environment variable that contains the name of your package from the project's definition file (pyproject.toml:project.name).
If you are using the PSR GitHub Action, you will need to add an installation command for uv to the build_command because the action runs in a Docker environment does not include uv by default. The best way to ensure that the correct version of uv is installed is to define the version of uv in an optional dependency list (e.g. build). This will also help with other automated tools like Dependabot or Renovate to keep the version of uv up to date.
[project.optional-dependencies] build = ["uv ~= 0.7.12"] [tool.semantic_release] build_command = """
python -m pip install -e '.[build]'
uv lock --upgrade-package "$PACKAGE_NAME"
git add uv.lock
uv build """
- 2.
- Stamp the code first & then separately run release: If you
prefer to not modify the build command, then you will need to run the
uv lock --upgrade-package <your-package-name> command prior
to actually creating the release. Essentially, you will run PSR twice: (1)
once to update the version in the project's definition file, and (2) a
second time to generate the release.
The intent of the uv lock --upgrade-package <your-package-name> command is ONLY to update the version of your project within the lock file after PSR has updated the version in your project's definition file (e.g., pyproject.toml). When you are running PSR, you have already tested the project as is and you don't want to actually update the dependencies if a new one just became available.
# 1. PSR stamps version into files (nothing else) # don't build the changelog (especially in update mode) semantic-release -v version --skip-build --no-commit --no-tag --no-changelog # 2. run UV lock as pyproject.toml is updated with the next version uv lock --upgrade-package <your-package-name> # 3. stage the lock file to ensure it is included in the PSR commit git add uv.lock # 4. run PSR fully to create release semantic-release -v version
Advanced Example
Of course, you can mix and match these 2 approaches as needed. If PSR's pipeline was using uv, we would have a mixture of the 2 approaches because we run the build in a separate job from the release. In our case, PSR would also need to carry the lock file as a workflow artifact along the pipeline for the release job to commit it. This advanced workflow would look like this:
# File: .tool-versions uv 0.7.12
# File: .python-version 3.11.11
# File: pyproject.toml [project.optional-dependencies] build = ["python-semantic-release ~= 10.0"] test = ["pytest ~= 8.0"] [tool.semantic_release] build_command = """
uv lock --upgrade-package "$PACKAGE_NAME"
uv build """
# File: .github/workflows/release.yml on:
push:
branches:
- main jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: read
env:
dist_artifacts_name: dist
dist_artifacts_dir: dist
lock_file_artifact: uv.lock
steps:
- name: Setup | Checkout Repository at workflow sha
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ github.sha }}
fetch-depth: 0
- name: Setup | Force correct release branch on workflow sha
run: git checkout -B ${{ github.ref_name }}
- name: Setup | Install uv
uses: asdf-vm/actions/install@1902764435ca0dd2f3388eea723a4f92a4eb8302 # v4.0.2
- name: Setup | Install Python & Project dependencies
run: uv sync --extra build
- name: Build | Build next version artifacts
id: version
env:
GH_TOKEN: "none"
run: uv run semantic-release -v version --no-changelog --no-commit --no-tag
- name: Upload | Distribution Artifacts
if: ${{ steps.version.outputs.released == 'true' }}
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: ${{ env.dist_artifacts_name }}
path: ${{ format('{0}/**', env.dist_artifacts_dir) }}
if-no-files-found: error
retention-days: 2
- name: Upload | Lock File Artifact
if: ${{ steps.version.outputs.released == 'true' }}
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: ${{ env.lock_file_artifact }}
path: ${{ env.lock_file_artifact }}
if-no-files-found: error
retention-days: 2
outputs:
new-release-detected: ${{ steps.version.outputs.released }}
new-release-version: ${{ steps.version.outputs.version }}
new-release-tag: ${{ steps.version.outputs.tag }}
new-release-is-prerelease: ${{ steps.version.outputs.is_prerelease }}
distribution-artifacts: ${{ env.dist_artifacts_name }}
lock-file-artifact: ${{ env.lock_file_artifact }}
test-e2e:
needs: build
runs-on: ubuntu-latest
steps:
- name: Setup | Checkout Repository
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ github.sha }}
fetch-depth: 1
- name: Setup | Download Distribution Artifacts
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
if: ${{ needs.build.outputs.new-release-detected == 'true' }}
id: artifact-download
with:
name: ${{ needs.build.outputs.distribution-artifacts }}
path: ./dist
- name: Setup | Install uv
uses: asdf-vm/actions/install@1902764435ca0dd2f3388eea723a4f92a4eb8302 # v4.0.2
- name: Setup | Install Python & Project dependencies
run: uv sync --extra test
- name: Setup | Install distribution artifact
if: ${{ steps.artifact-download.outcome == 'success' }}
run: |
uv pip uninstall my-package
uv pip install dist/python_semantic_release-*.whl
- name: Test | Run pytest
run: uv run pytest -vv tests/e2e
release:
runs-on: ubuntu-latest
needs:
- build
- test-e2e
if: ${{ needs.build.outputs.new-release-detected == 'true' }}
concurrency:
group: ${{ github.workflow }}-release-${{ github.ref_name }}
cancel-in-progress: false
permissions:
contents: write
steps:
- name: Setup | Checkout Repository on Release Branch
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: ${{ github.ref_name }}
fetch-depth: 0
- name: Setup | Force release branch to be at workflow sha
run: git reset --hard ${{ github.sha }}
- name: Setup | Install uv
uses: asdf-vm/actions/install@1902764435ca0dd2f3388eea723a4f92a4eb8302 # v4.0.2
- name: Setup | Install Python & Project dependencies
run: uv sync --extra build
- name: Setup | Download Build Artifacts
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
id: artifact-download
with:
name: ${{ needs.build.outputs.distribution-artifacts }}
path: dist
- name: Setup | Download Lock File Artifact
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
with:
name: ${{ needs.build.outputs.lock-file-artifact }}
- name: Setup | Stage Lock File for Version Commit
run: git add uv.lock
- name: Release | Create Release
id: release
shell: bash
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
bash .github/workflows/verify_upstream.sh
uv run semantic-release -v --strict version --skip-build
uv run semantic-release publish
outputs:
released: ${{ steps.release.outputs.released }}
new-release-version: ${{ steps.release.outputs.version }}
new-release-tag: ${{ steps.release.outputs.tag }}
deploy:
name: Deploy
runs-on: ubuntu-latest
if: ${{ needs.release.outputs.released == 'true' && github.repository == 'python-semantic-release/my-package' }}
needs:
- build
- release
environment:
name: pypi
url: https://pypi.org/project/my-package/
permissions:
id-token: write
steps:
- name: Setup | Download Build Artifacts
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
id: artifact-download
with:
name: ${{ needs.build.outputs.distribution-artifacts }}
path: dist
- name: Publish package distributions to PyPI
uses: pypa/gh-action-pypi-publish@76f52bc884231f62b9a034ebfe128415bbaabdfc # v1.12.4
with:
packages-dir: dist
print-hash: true
verbose: true
Configuration¶
Configuration is read from a file which can be specified using the \\-\\-config option to cmd-main. Python Semantic Release currently supports a configuration in either TOML or JSON format, and will attempt to auto-detect and parse either format.
When using a JSON-format configuration file, Python Semantic Release looks for its settings beneath a top-level semantic_release key; when using a TOML-format configuration file, Python Semantic Release first checks for its configuration under the table [tool.semantic_release] (in line with the convention for Python tools to require their configuration under the top-level tool table in their pyproject.toml file), followed by [semantic_release], which may be more desirable if using a file other than the default pyproject.toml for configuration.
The examples on this page are given in TOML format, however there is no limitation on using JSON instead. In fact, if you would like to convert any example below to its JSON equivalent, the following commands will do this for you (in Bash):
export TEXT="<the TOML to convert>"
cat <<EOF | python3
import tomlkit, json
print(json.dumps(tomlkit.loads('''$TEXT'''), indent=4))
EOF
A note on null¶
In TOML, there is no such thing as a "null" or "nil" value, and this isn't planned as a language feature according to the relevant GitHub issue. In Python Semantic Release, options which default to None are inferred from the relevant configuration settings not being present at all in your configuration. Because of this limitation, it's currently not possible to explicitly specify those settings as "null" in TOML-format configuration. Technically it is possible in JSON-format configuration, but it's recommended to keep consistency and just omit the relevant settings.
Environment Variables¶
Some settings are best pulled from environment variables rather than being stored in plaintext in your configuration file. Python Semantic Release can be configured to look for an environment variable value to use for a given setting, but this feature is not available for all settings. In order to use an environment variable for a setting, you must indicate in your configuration file the name of the environment variable to use.
The traditional and most common use case for environment variable use is for passing authentication tokens to Python Semantic Release. You do NOT want to hard code your authentication token in your configuration file, as this is a security risk. A plaintext token in your configuration file could be exposed to anyone with access to your repository, including long after its deleted if a token is in your git history. Instead, define the name of the environment variable which contains your remote.token, such as GH_TOKEN, in your configuration file, and Python Semantic Release will do the rest, as seen below.
[semantic_release.remote.token] env = "GH_TOKEN"
Given basic TOML syntax compatibility, this is equivalent to:
[semantic_release.remote]
token = { env = "GH_TOKEN" }
The general format for specifying that some configuration should be sourced from an environment variable is:
[semantic_release.variable] env = "ENV_VAR" default_env = "FALLBACK_ENV_VAR" default = "default value"
In this structure:
- env represents the environment variable that Python Semantic Release will search for
- default_env is a fallback environment variable to read in case the variable specified by env is not set. This is optional - if not specified then no fallback will be used.
- default is a default value to use in case the environment variable specified by env is not set. This is optional - if default is not specified then the environment variable specified by env is considered required.
semantic_release settings¶
The following sections outline all the definitions and descriptions of each supported configuration setting. If there are type mis-matches, PSR will throw validation errors upon load. If a setting is not provided, than PSR will fill in the value with the default value.
Python Semantic Release expects a root level key to start the configuration definition. Make sure to use the correct root key depending on the configuration format you are using.
NOTE:
NOTE:
NOTE:
----
allow_zero_version¶
Introduced in v9.2.0
Type: bool
This flag controls whether or not Python Semantic Release will use version numbers aligning with the 0.x.x pattern.
If set to true and starting at 0.0.0, a minor bump would set the next version as 0.1.0 whereas a patch bump would set the next version as 0.0.1. A breaking change (ie. major bump) would set the next version as 1.0.0 unless the major_on_zero is set to false.
If set to false, Python Semantic Release will consider the first possible version to be 1.0.0, regardless of patch, minor, or major change level. Additionally, when allow_zero_version is set to false, the major_on_zero setting is ignored.
Default changed to ``false`` in v10.0.0
Default: false
----
assets¶
Type: list[str]
One or more paths to additional assets that should committed to the remote repository in addition to any files modified by writing the new version.
Default: []
----
branches¶
This setting is discussed in more detail at Multibranch Releases
Default:
[semantic_release.branches.main] match = "(main|master)" prerelease_token = "rc" prerelease = false
----
build_command¶
Type: Optional[str]
Command to use to build the current project during cmd-version.
Python Semantic Release will execute the build command in the OS default shell with a subset of environment variables. PSR provides the variable NEW_VERSION in the environment with the value of the next determined version. The following table summarizes all the environment variables that are passed on to the build_command runtime if they exist in the parent process.
If you would like to pass additional environment variables to your build command, see build_command_env.
| Variable Name | Description |
| CI | Pass-through true if exists in process env, unset otherwise |
| BITBUCKET_CI | true if Bitbucket CI variables exist in env, unset otherwise |
| GITHUB_ACTIONS | Pass-through true if exists in process env, unset otherwise |
| GITEA_ACTIONS | Pass-through true if exists in process env, unset otherwise |
| GITLAB_CI | Pass-through true if exists in process env, unset otherwise |
| HOME | Pass-through HOME of parent process |
| NEW_VERSION | Semantically determined next version (ex. 1.2.3) |
| PATH | Pass-through PATH of parent process |
| PACKAGE_NAME | Project name as defined in pyproject.toml:project.name |
| PSR_DOCKER_GITHUB_ACTION | Pass-through true if exists in process env, unset otherwise |
| VIRTUAL_ENV | Pass-through VIRTUAL_ENV if exists in process env, unset otherwise |
In addition, on windows systems these environment variables are passed:
| Variable Name | Description |
| ALLUSERSAPPDATA | Pass-through ALLUSERAPPDATA if exists in process env, unset otherwise |
| ALLUSERSPROFILE | Pass-through ALLUSERSPPPROFILE if exists in process env, unset otherwise |
| APPDATA | Pass-through APPDATA if exists in process env, unset otherwise |
| COMMONPROGRAMFILES | Pass-through COMMONPROGRAMFILES if exists in process env, unset otherwise |
| COMMONPROGRAMFILES(X86) | Pass-through COMMONPROGRAMFILES(X86) if exists in process env, unset otherwise |
| DEFAULTUSERPROFILE | Pass-through DEFAULTUSERPROFILE if exists in process env, unset otherwise |
| HOMEPATH | Pass-through HOMEPATH if exists in process env, unset otherwise |
| PATHEXT | Pass-through PATHEXT if exists in process env, unset otherwise |
| PROFILESFOLDER | Pass-through PROFILESFOLDER if exists in process env, unset otherwise |
| PROGRAMFILES | Pass-through PROGRAMFILES if exists in process env, unset otherwise |
| PROGRAMFILES(X86) | Pass-through PROGRAMFILES(X86) if exists in process env, unset otherwise |
| SYSTEM | Pass-through SYSTEM if exists in process env, unset otherwise |
| SYSTEM16 | Pass-through SYSTEM16 if exists in process env, unset otherwise |
| SYSTEM32 | Pass-through SYSTEM32 if exists in process env, unset otherwise |
| SYSTEMDRIVE | Pass-through SYSTEMDRIVE if exists in process env, unset otherwise |
| SYSTEMROOT | Pass-through SYSTEMROOT if exists in process env, unset otherwise |
| TEMP | Pass-through TEMP if exists in process env, unset otherwise |
| TMP | Pass-through TMP if exists in process env, unset otherwise |
| USERPROFILE | Pass-through USERPROFILE if exists in process env, unset otherwise |
| USERSID | Pass-through USERSID if exists in process env, unset otherwise |
| WINDIR | Pass-through WINDIR if exists in process env, unset otherwise |
Default: None (not specified)
----
build_command_env¶
Introduced in v9.7.2
Type: Optional[list[str]]
List of environment variables to include or pass-through on to the build command that executes during cmd-version.
This configuration option allows the user to extend the list of environment variables from the table above in build_command. The input is a list of strings where each individual string handles a single variable definition. There are two formats accepted and are detailed in the following table:
| FORMAT | Description |
| VAR_NAME | Detects value from the PSR process environment, and passes value to build_command process |
| VAR_NAME=value | Sets variable name to value inside of build_command process |
NOTE:
Default: None (not specified)
----
changelog¶
This section outlines the configuration options available that modify changelog generation.
NOTE:
releaserc.toml: [semantic_release.changelog]
releaserc.json: { "semantic_release": { "changelog": {} } }
----
changelog_file¶
WARNING:
Type: str
Specify the name of the changelog file that will be created. This file will be created or overwritten (if it previously exists) with the rendered default template included with Python Semantic Release.
Depending on the file extension of this setting, the changelog will be rendered in the format designated by the extension. PSR, as of v9.11.0, provides a default changelog template in both Markdown (.md) and reStructuredText (.rst) formats. If the file extension is not recognized, the changelog will be rendered in Markdown format, unless the output_format setting is set.
If you are using the template_dir setting for providing customized templates, this setting is not used. See template_dir for more information.
Default: "CHANGELOG.md"
----
default_templates¶
NOTE:
pyproject.toml: [tool.semantic_release.changelog.default_templates]
releaserc.toml: [semantic_release.changelog.default_templates]
releaserc.json: { "semantic_release": { "changelog": { "default_templates": {} } } }
----
changelog_file¶
Introduced in v9.11.0.
Type: str
Specify the name of the changelog file that will be created. This file will be created or overwritten (if it previously exists) with the rendered default template included with Python Semantic Release.
Depending on the file extension of this setting, the changelog will be rendered in the format designated by the extension. PSR, as of v9.11.0, provides a default changelog template in both Markdown (.md) and reStructuredText (.rst) formats. If the file extension is not recognized, the changelog will be rendered in Markdown format, unless the output_format setting is set.
If you are using the template_dir setting for providing customized templates, this setting is not used. See template_dir for more information.
Default: "CHANGELOG.md"
----
mask_initial_release¶
Introduced in v9.14.0
Type: bool
This option toggles the behavior of the changelog and release note templates to mask the release details specifically for the first release. When set to true, the first version release notes will be masked with a generic message as opposed to the usual commit details. When set to false, the release notes will be generated as normal.
The reason for this setting is to improve clarity to your audience. It conceptually does NOT make sense to have a list of changes (i.e. a Changelog) for the first release since nothing has been published yet, therefore in the eyes of your consumers what change is there to document?
The message details can be found in the first_release.md.j2 and first_release.rst.j2 templates of the default changelog template directory.
Default changed to ``true`` in v10.0.0.
Default: true
SEE ALSO:
- •
- Using the Default Changelog
----
output_format¶
Introduced in v9.10.0
Type: Literal["md", "rst"]
This setting is used to specify the output format the default changelog template will use when rendering the changelog. PSR supports both Markdown (md) and reStructuredText (rst) formats.
This setting will take precedence over the file extension of the changelog_file setting. If this setting is omitted, the file extension of the changelog_file setting will be used to determine the output format. If the file extension is not recognized, the output format will default to Markdown.
Default: "md"
SEE ALSO:
- •
- changelog_file
----
environment¶
NOTE:
releaserc.toml: [semantic_release.changelog.environment]
releaserc.json: { "semantic_release": { "changelog": { "environment": {} } } }
----
autoescape¶
Type: Union[str, bool]
If this setting is a string, it should be given in module:attr form; Python Semantic Release will attempt to dynamically import this string, which should represent a path to a suitable callable that satisfies the following:
The result of this dynamic import is passed directly to the jinja2.Environment constructor.
If this setting is a boolean, it is passed directly to the jinja2.Environment constructor.
Default: false
----
block_start_string¶
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "{%"
----
block_end_string¶
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "%}"
----
comment_start_string¶
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: {#
----
comment_end_string¶
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "#}"
----
extensions¶
Type: list[str]
This setting is passed directly to the jinja2.Environment constructor.
Default: []
----
keep_trailing_newline¶
Type: bool
This setting is passed directly to the jinja2.Environment constructor.
Default: false
----
line_comment_prefix¶
Type: Optional[str]
This setting is passed directly to the jinja2.Environment constructor.
Default: None (not specified)
----
line_statement_prefix¶
Type: Optional[str]
This setting is passed directly to the jinja2.Environment constructor.
Default: None (not specified)
----
lstrip_blocks¶
Type: bool
This setting is passed directly to the jinja2.Environment constructor.
Default: false
----
newline_sequence¶
Type: Literal["\n", "\r", "\r\n"]
This setting is passed directly to the jinja2.Environment constructor.
Default: "\n"
----
trim_blocks¶
Type: bool
This setting is passed directly to the jinja2.Environment constructor.
Default: false
----
variable_start_string¶
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "{{"
----
variable_end_string¶
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "}}"
----
exclude_commit_patterns¶
Type: list[str]
Any patterns specified here will be excluded from the commits which are available to your changelog. This allows, for example, automated commits to be removed if desired. Python Semantic Release also removes its own commits from the Changelog via this mechanism; therefore if you change the automated commit message that Python Semantic Release uses when making commits, you may wish to add the old commit message pattern here.
The patterns in this list are treated as regular expressions.
Default: []
----
mode¶
Introduced in v9.10.0. Default changed to `update` in v10.0.0.
Type: Literal["init", "update"]
This setting is a flag that is ultimately passed into the changelog context environment. It sets the value of context.changelog_mode to a string value of either init or update.
When used with the provided changelog template, it will determine the behavior of how the changelog is written. When the mode is set to init, the changelog file will be written from scratch, overwriting any existing changelog file. This is the v8 and v9 default behavior.
When the mode is set to update, the changelog file will look for the insertion_flag value in the changelog file (defined by changelog_file) and insert the new version information at that location.
If you are using a custom template directory, the context.changelog_mode value will exist in the changelog context but it is up to your implementation to determine if and/or how to use it.
Default: update
SEE ALSO:
- •
- Using the Default Changelog
----
insertion_flag¶
Introduced in v9.10.0
Type: str
A string that will be used to identify where the new version should be inserted into the changelog file (as defined by changelog_file) when the changelog mode is set to update.
If you modify this value in your config, you will need to manually update any saved changelog file to match the new insertion flag if you use the update mode. In init mode, the changelog file will be overwritten as normal.
In v9.11.0, the insertion_flag default value became more dynamic with the introduction of an reStructuredText template. The default value will be set depending on the output_format setting. The default flag values are:
| Output Format | Default Insertion Flag |
| Markdown (md) | <!-- version list --> |
| reStructuredText | ..\n version list |
Default: various, see above
----
template_dir¶
Type: str
When files exist within the specified directory, they will be used as templates for the changelog rendering process. Regardless if the directory includes a changelog file, the provided directory will be rendered and files placed relative to the root of the project directory.
No default changelog template or release notes template will be used when this directory exists and the directory is not empty. If the directory is empty, the default changelog template will be used.
This option is discussed in more detail at Version Change Reports
Default: "templates"
----
commit_author¶
Type: str
Author used in commits in the format name <email>.
NOTE:
SEE ALSO:
- •
- GitHub Actions
Default: semantic-release <semantic-release>
----
commit_message¶
Type: str
Commit message to use when making release commits. The message can use {version} as a format key, in which case the version being released will be formatted into the message.
If at some point in your project's lifetime you change this, you may wish to consider, adding the old message pattern(s) to exclude_commit_patterns.
Default: "{version}\n\nAutomatically generated by python-semantic-release"
----
commit_parser¶
Type: str
Specify which commit parser Python Semantic Release should use to parse the commits within the Git repository.
- angular - AngularCommitParser (deprecated in v9.19.0)
- conventional - ConventionalCommitParser (available in v9.19.0+)
- conventional-monorepo - ConventionalCommitMonorepoParser (available in v10.4.0+)
- emoji - EmojiCommitParser
- scipy - ScipyCommitParser
- tag - TagCommitParser (deprecated in v9.12.0)
You can set any of the built-in parsers by their keyword but you can also specify your own commit parser in path/to/module_file.py:Class or module:Class form.
For more information see Commit Parsing.
Default: "conventional"
----
commit_parser_options¶
Type: dict[str, Any]
This set of options are passed directly to the commit parser class specified in the commit parser configuration option.
For more information (to include defaults), see Customization.
Default: ParserOptions { ... }, where ... depends on commit_parser.
----
logging_use_named_masks¶
Type: bool
Whether or not to replace secrets identified in logging messages with named masks identifying which secrets were replaced, or use a generic string to mask them.
Default: false
----
major_on_zero¶
Type: bool
This flag controls whether or not Python Semantic Release will increment the major version upon a breaking change when the version matches 0.y.z. This value is set to true by default, where breaking changes will increment the 0 major version to 1.0.0 like normally expected.
If set to false, major (breaking) releases will increment the minor digit of the version while the major version is 0, instead of the major digit. This allows for continued breaking changes to be made while the major version remains 0.
From the Semantic Versioning Specification:
When you are ready to release a stable version, set major_on_zero to true and run Python Semantic Release again. This will increment the major version to 1.0.0.
When allow_zero_version is set to false, this setting is ignored.
Default: true
----
no_git_verify¶
Introduced in v9.8.0
Type: bool
This flag is passed along to git upon performing a git commit during cmd-version.
When true, it will bypass any git hooks that are set for the repository when Python Semantic Release makes a version commit. When false, the commit is performed as normal. This option has no effect when there are not any git hooks configured nor when the --no-commit option is passed.
Default: false
----
publish¶
This section defines configuration options that modify cmd-publish.
NOTE:
releaserc.toml: [semantic_release.publish]
releaserc.json: { "semantic_release": { "publish": {} } }
----
dist_glob_patterns¶
Type: list[str]
Upload any files matching any of these globs to your VCS release. Each item in this list should be a string containing a Unix-style glob pattern.
Default: ["dist/*"]
----
upload_to_vcs_release¶
Type: bool
If set to true, upload any artifacts matched by the dist_glob_patterns to the release created in the remote VCS corresponding to the latest tag. Artifacts are only uploaded if release artifact uploads are supported by the VCS type.
Default: true
----
remote¶
The remote configuration is a group of settings that configure PSR's integration with remote version control systems.
NOTE:
releaserc.toml: [semantic_release.remote]
releaserc.json: { "semantic_release": { "remote": {} } }
----
api_domain¶
Type: Optional[str | Dict['env', str]]
The hosting domain for the API of your remote HVCS if different than the domain. Generally, this will be used to specify a separate subdomain that is used for API calls rather than the primary domain (ex. api.github.com).
Most on-premise HVCS installations will NOT use this setting! Whether or not this value is used depends on the HVCS configured (and your server administration) in the remote.type setting and used in tandem with the remote.domain setting.
When using a custom remote.domain and a HVCS remote.type that is configured with a separate domain or sub-domain for API requests, this value is used to configure the location of API requests that are sent from PSR.
Most on-premise or self-hosted HVCS environments will use a path prefix to handle inbound API requests, which means this value will ignored.
PSR knows the expected api domains for known cloud services and their associated api domains which means this value is not necessary to explicitly define for services as bitbucket.org, and github.com.
Including the protocol schemes, such as https://, for the API domain is optional. Secure HTTPS connections are assumed unless the setting of remote.insecure is true.
Default: None
----
domain¶
Type: Optional[str | Dict['env', str]]
The host domain for your HVCS server. This setting is used to support on-premise installations of HVCS providers with custom domain hosts.
If you are using the official domain of the associated remote.type, this value is not required. PSR will use the default domain value for the remote.type when not specified. For example, when remote.type="github" is specified the default domain of github.com is used.
Including the protocol schemes, such as https://, for the domain value is optional. Secure HTTPS connections are assumed unless the setting of remote.insecure is true.
This setting also supports reading from an environment variable for ease-of-use in CI pipelines. See Environment Variable for more information. Depending on the remote.type, the default environment variable for the default domain's CI pipeline environment will automatically be checked so this value is not required in default environments. For example, when remote.type="gitlab" is specified, PSR will look to the CI_SERVER_URL environment variable when remote.domain is not specified.
Default: None
SEE ALSO:
- •
- remote.api_domain
----
ignore_token_for_push¶
Type: bool
If set to true, ignore the authentication token when pushing changes to the remote. This is ideal, for example, if you already have SSH keys set up which can be used for pushing.
Default: false
----
insecure¶
Introduced in v9.4.2
Type: bool
Insecure is used to allow non-secure HTTP connections to your HVCS server. If set to true, any domain value passed will assume http:// if it is not specified and allow it. When set to false (implicitly or explicitly), it will force https:// communications.
When a custom domain or api_domain is provided as a configuration, this flag governs the protocol scheme used for those connections. If the protocol scheme is not provided in the field value, then this insecure option defines whether HTTP or HTTPS is used for the connection. If the protocol scheme is provided in the field value, it must match this setting or it will throw an error.
The purpose of this flag is to prevent any typos in provided domain and api_domain values that accidentally specify an insecure connection but allow users to toggle the protection scheme off when desired.
Default: false
----
name¶
Type: str
Name of the remote to push to using git push -u $name <branch_name>
Default: "origin"
----
token¶
Type: Optional[str | Dict['env', str]]
Environment Variable from which to source the authentication token for the remote VCS. Common examples include "GH_TOKEN", "GITLAB_TOKEN" or "GITEA_TOKEN", however, you may choose to use a custom environment variable if you wish.
NOTE:
If your push access is enabled via SSH keys instead, then you do not need to set this environment variable in order to push the version increment, changelog and modified source code assets to the remote using cmd-version. However, you will need to disable release creation using the cmd-version-option-vcs-release option, among other options, in order to use Python Semantic Release without configuring the environment variable for your remote VCS authentication token.
The default value for this setting depends on what you specify as remote.type. Review the table below to see what the default token value will be for each remote type.
| remote.type | Default remote.token | |
| "github" | -> | { env = "GH_TOKEN" } |
| "gitlab" | -> | { env = "GITLAB_TOKEN" } |
| "gitea" | -> | { env = "GITEA_TOKEN" } |
| "bitbucket" | -> | { env = "BITBUCKET_TOKEN" } |
Default: { env = "<envvar name>" }, where <envvar name> depends on remote.type as indicated above.
----
type¶
Type: Literal["bitbucket", "gitea", "github", "gitlab"]
The type of the remote VCS. Currently, Python Semantic Release supports "github", "gitlab", "gitea" and "bitbucket". Not all functionality is available with all remote types, but we welcome pull requests to help improve this!
Default: "github"
----
url¶
Type: Optional[str | Dict['env', str]]
An override setting used to specify the remote upstream location of git push.
Not commonly used! This is used to override the derived upstream location when the desired push location is different than the location the repository was cloned from.
This setting will override the upstream location url that would normally be derived from the remote.name location of your git repository.
Default: None
----
tag_format¶
Type: str
Specify the format to be used for the Git tag that will be added to the repo during a release invoked via cmd-version. The format string is a regular expression, which also must include the format keys below, otherwise an exception will be thrown. It may include any of the optional format keys, in which case the contents described will be formatted into the specified location in the Git tag that is created.
For example, "(dev|stg|prod)-v{version}" is a valid tag_format matching tags such as:
- dev-v1.2.3
- stg-v0.1.0-rc.1
- prod-v2.0.0+20230701
This format will also be used for parsing tags already present in the repository into semantic versions; therefore if the tag format changes at some point in the repository's history, historic versions that no longer match this pattern will not be considered as versions.
| Format Key | Mandatory | Contents |
| {version} | Yes | The new semantic version number, for example 1.2.3, or 2.1.0-alpha.1+build.1234 |
Tags which do not match this format will not be considered as versions of your project.
Default: "v{version}"
----
version_toml¶
Type: list[str]
This configuration option is similar to version_variables, but it uses a TOML parser to interpret the data structure before, inserting the version. This allows users to use dot-notation to specify the version via the logical structure within the TOML file, which is more accurate than a pattern replace.
The version_toml option is commonly used to update the version number in the project definition file: pyproject.toml as seen in the example below.
As of v9.20.0, the version_toml option accepts a colon-separated definition with either 2 or 3 parts. The 2-part definition includes the file path and the version parameter (in dot-notation). Newly with v9.20.0, it also accepts an optional 3rd part to allow configuration of the format type.
Available Format Types
- nf: Number format (ex. 1.2.3)
- tf: Tag Format (ex. v1.2.3)
If the format type is not specified, it will default to the number format.
Example
[semantic_release] version_toml = [
# "file:variable:[format_type]"
"pyproject.toml:tool.poetry.version", # Implied Default: Number format
"definition.toml:project.version:nf", # Number format
"definition.toml:project.release:tf", # Tag format ]
This configuration will result in the following changes:
diff a/pyproject.toml b/pyproject.toml
[tool.poetry] - version = "0.1.0" + version = "0.2.0"
diff a/definition.toml b/definition.toml
[project]
name = "example" - version = "0.1.0" + version = "0.1.0" - release = "v0.1.0" + release = "v0.2.0"
Default: []
----
version_variables¶
Type: list[str]
The version_variables configuration option is a list of string definitions that defines where the version number should be updated in the repository, when a new version is released.
As of v9.20.0, the version_variables option accepts a colon-separated definition with either 2 or 3 parts. The 2-part definition includes the file path and the variable name. Newly with v9.20.0, it also accepts an optional 3rd part to allow configuration of the format type.
Available Format Types
- nf: Number format (ex. 1.2.3)
- tf: Tag Format (ex. v1.2.3)
If the format type is not specified, it will default to the number format.
Prior to v9.20.0, PSR only supports entries with the first 2-parts as the tag format type was not available and would only replace numeric version numbers.
Example
[semantic_release]
tag_format = "v{version}"
version_variables = [
# "file:variable:format_type"
"src/semantic_release/__init__.py:__version__", # Implied Default: Number format
"docs/conf.py:version:nf", # Number format for sphinx docs
"kustomization.yml:newTag:tf", # Tag format
]
First, the __version__ variable in src/semantic_release/__init__.py will be updated with the next version using the SemVer number format.
diff a/src/semantic_release/__init__.py b/src/semantic_release/__init__.py - __version__ = "0.1.0" + __version__ = "0.2.0"
Then, the version variable in docs/conf.py will be updated with the next version with the next version using the SemVer number format because of the explicit nf.
diff a/docs/conf.py b/docs/conf.py - version = "0.1.0" + version = "0.2.0"
Lastly, the newTag variable in kustomization.yml will be updated with the next version with the next version using the configured tag_format because the definition included tf.
diff a/kustomization.yml b/kustomization.yml
images:
- name: repo/image - newTag: v0.1.0 + newTag: v0.2.0
How It works
Each version variable will be transformed into a Regular Expression that will be used to substitute the version number in the file. The replacement algorithm is ONLY a pattern match and replace. It will NOT evaluate the code nor will PSR understand any internal object structures (ie. file:object.version will not work).
The regular expression generated from the version_variables definition will:
- 1.
- Look for the specified variable name in the file. The variable name can be enclosed by single (') or double (") quotation marks but they must match.
- 2.
- The variable name defined by variable and the version must be separated by an operand symbol (=, :, :=, or @). Whitespace is optional around the symbol. As of v10.0.0, a double-equals (==) operator is also supported as a valid operand symbol.
- 3.
- The value of the variable must match a SemVer regular expression and can be enclosed by single (') or double (") quotation marks but they must match. However, the enclosing quotes of the value do not have to match the quotes surrounding the variable name.
- 4.
- If the format type is set to tf then the variable value must have the matching prefix and suffix of the tag_format setting around the SemVer version number.
Given the pattern matching nature of this feature, the Regular Expression is able to support most file formats because of the similarity of variable declaration across programming languages. PSR specifically supports Python, YAML, and JSON as these have been the most commonly requested formats. This configuration option will also work regardless of file extension because it looks for a matching pattern string.
NOTE:
This is a comprehensive list (but not all variations) of examples where the following versions will be matched and replaced by the new version:
# Common variable declaration formats version='1.2.3' version = "1.2.3" release = "v1.2.3" # if tag_format is set # YAML version: 1.2.3 # JSON "version": "1.2.3" # NPM & GitHub Actions YAML version@1.2.3 version@v1.2.3 # if tag_format is set # Walrus Operator version := "1.2.3" # Excessive whitespace version = '1.2.3' # Mixed Quotes "version" = '1.2.3' # Custom Tag Format with tag_format set (monorepos) __release__ = "module-v1.2.3" # requirements.txt my-package == 1.2.3
IMPORTANT:
This may become more flexible in the future with resolution of issue #941.
WARNING:
Default: []
Automated Releases¶
The key point with using this package is to automate your releases and stop worrying about version numbers. Different approaches to automatic releases and publishing with the help of this package can be found below. Using a CI is the recommended approach.
Guides¶
Travis CI¶
This guide expects you to have activated the repository on Travis CI. If this is not the case, please refer to Travis documentation on how to do that.
1. Add python-semantic-release settings¶
See Configuration for details on how to configure Python Semantic Release. Make sure that at least you have set version_variables before continuing.
2. Add environment variables¶
You will need to set up an environment variable in Travis. An easy way to do that is to go to the settings page for your package and add it there. Make sure that the secret toggle is set correctly.
You need to set the GH_TOKEN environment variable with a personal access token for Github. It will need either repo or public_repo scope depending on whether the repository is private or public.
More information on how to set environment variables can be found on Travis documentation on environment variables.
3. Add travis configuration¶
The following should be added to your .travis.yml file.
after_success: - git config --global user.name "semantic-release (via TravisCI)" - git config --global user.email "semantic-release@travis" - pip install python-semantic-release - semantic-release version && semantic-release publish
The first line tells Travis that we want to run the listed tasks after a successful build. The two first lines in after_success will configure git so that python-semantic-release will be able to commit on Travis. The third installs the latest version of python-semantic-release. The last will run the publish command, which will publish a new version if the changes indicate that one is due.
4. Push some changes¶
You are now ready to release automatically on Travis CI on every change to your master branch.
Happy coding!
GitHub Actions¶
There are two official GitHub Actions for Python Semantic Release:
- 1.
- python-semantic-release/python-semantic-release@TAG
- This is the main action that runs the version CLI command. It is used to (1) determine the next version number, (2) stamp the version number, (3) run the build command, (4) build the changelog, (5) commit the changes, (6) tag the commit, (7) publish the commit & tag and lastly (8) create a GitHub release. For more information review the version command documentation and see below for the Action configuration options.
- 2.
- python-semantic-release/publish-action@TAG
- This action is used to execute the publish CLI command. It is used to upload files, such as distribution artifacts and other assets, to a GitHub release.
Included in this documentation are some recommended examples below if you want to get started quickly. These examples are not exhaustive and you will need to adjust them for your specific project needs especially if you are using a monorepo.
- GitHub Actions Example Workflows
- GitHub Actions with Monorepos
NOTE:
Python Semantic Release Action¶
The official Python Semantic Release GitHub Action is a GitHub Docker Action, which means at the beginning of the job it will build a Docker image that contains the Python Semantic Release package and its dependencies. It will then run the job step inside the Docker Container. This is done to ensure that the environment is consistent across all GitHub Runners regardless of platform. With this choice, comes some limitations of non-configurable options like a pre-defined python version, lack of installed build tools, and an inability to utilize caching.
The primary benefit of using the GitHub Action is that it is easy to set up and use for most projects. We handle a lot of the git configuration under the hood, so you don't have to handle it yourself. There are a plenty of customization options available which are detailed individually below.
Most importantly your project's configuration file will be used as normal, as your project will be mounted into the container for the action to use.
SEE ALSO:
Inputs¶
GitHub Action inputs are used for select configuration and provide the necessary information to execute the action. The inputs are passed to the action using the with keyword in the workflow file. Many inputs will mirror the command line options available in the version command. This section outlines each supported input and its purpose.
----
build¶
Type: Literal["true", "false"]
Override whether the action should execute the build command or not. This option is equivalent to adding the command line switch --skip-build (when false) to the version command. If set to true, no command line switch is passed and the default behavior of the version is used.
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-skip_build option for the version command.
----
build_metadata¶
Type: string
Explicitly set the build metadata of the version. This is equivalent to running the command:
semantic-release version --build-metadata <metadata>
Required: false
SEE ALSO:
- •
- cmd-version-option-build-metadata option for the version command
----
changelog¶
Type: Literal["true", "false"]
Override whether the action should generate a changelog or not. This option is equivalent to adding either --changelog (on true) or --no-changelog (on false) to the version command.
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-changelog options for the version command
----
commit¶
Type: Literal["true", "false"]
Override whether the action should commit any changes to the local repository. Changes include the version stamps, changelog, and any other files that are modified and added to the index during the build command. This option is equivalent to adding either --commit (on true) or --no-commit (on false) to the version command.
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-commit options for the version command
----
config_file¶
Path to a custom semantic-release configuration file. By default, an empty string will look for to the pyproject.toml file in the current directory. This is the same as passing the -c or --config parameter to semantic-release.
Required: false
Default: ""
SEE ALSO:
- •
- cmd-main-option-config for the semantic-release command
----
directory¶
If the project is not at the root of the repository (like in monorepos), you can specify a sub-directory to change into before running semantic-release.
Required: false
Default: .
----
force¶
Type: Literal["prerelease", "patch", "minor", "major"]
Force the next version to be a specific bump type. This is equivalent to running the command:
semantic-release version --<type> # Ex: force a patch level version bump semantic-release version --patch
Required: false
SEE ALSO:
- •
- cmd-version-option-force-level options for the version command
----
git_committer_email¶
The email of the account used to commit. If customized, it must be associated with the provided token.
Required: false
----
git_committer_name¶
The name of the account used to commit. If customized, it must be associated with the provided token.
Required: false
----
github_token¶
The GitHub Token is essential for access to your GitHub repository to allow the push of commits & tags as well as to create a release. Not only do you need to provide the token as an input but you also need to ensure that the token has the correct permissions.
The token should have the following permissions:
- id-token: write
- contents: write
Required: true
----
no_operation_mode¶
If set to true, the github action will pass the --noop parameter to semantic-release. This will cause semantic-release to run in "no operation" mode.
This is useful for testing the action without making any permanent changes to the repository.
Required: false
Default: false
SEE ALSO:
- •
- cmd-main-option-noop option for the semantic-release command
----
prerelease¶
Force the version to be a prerelease version when set to true. This is equivalent to running the command:
semantic-release version --as-prerelease
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-as-prerelease option for the version command
----
prerelease_token¶
Override any prerelease token in the configuration file with this value, if it is a pre-release. This will override the matching release branch configuration's prerelease_token value. If you always want it to be a prerelease then you must also set the prerelease input to true.
This option is equivalent to running the command:
semantic-release version --prerelease-token <token>
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-prerelease-token option for the version command
----
push¶
Type: Literal["true", "false"]
Override whether the action should push any commits or tags from the local repository to the remote repository. This option is equivalent to adding either --push (on true) or --no-push (on false) to the version command.
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-push options for the version command
----
root_options¶
IMPORTANT:
Additional options for the main semantic-release command, which will come before the version subcommand.
- uses: python-semantic-release/python-semantic-release@v9
with:
root_options: "-vv --noop"
This configuration would cause the command to be semantic-release -vv --noop version, which would run the version command verbosely but in no-operation mode.
Required: false
Default: -v
SEE ALSO:
- •
- Options for the semantic-release command
----
ssh_public_signing_key¶
The public key associated with the private key used in signing a commit and tag.
Required: false
----
ssh_private_signing_key¶
The private key used to sign a commit and tag.
Required: false
----
strict¶
If set to true, the github action will pass the --strict parameter to semantic-release.
SEE ALSO:
- •
- cmd-main-option-strict option for the semantic-release command
----
tag¶
Type: Literal["true", "false"]
Override whether the action should create a version tag in the local repository. This option is equivalent to adding either --tag (on true) or --no-tag (on false) to the version command.
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-tag options for the version command
----
vcs_release¶
Type: Literal["true", "false"]
Override whether the action should create a release on the VCS. This option is equivalent to adding either --vcs-release (on true) or --no-vcs-release (on false) to the version command.
Required: false
NOTE:
SEE ALSO:
- •
- cmd-version-option-vcs-release options for the version command
----
verbosity¶
Set the verbosity level of the output as the number of -v's to pass to semantic-release. 0 is no extra output, 1 is info level output, 2 is debug output, and 3 is a silly amount of debug output.
Required: false
Default: "1"
SEE ALSO:
- •
- cmd-main-option-verbosity for the semantic-release command
----
Outputs¶
The Python Semantic Release Action also provides outputs that can be used in subsequent steps of the workflow. These outputs are used to provide information about the release and any actions that were taken.
----
commit_sha¶
Type: string
The commit SHA of the release if a release was made, otherwise an empty string.
Example upon release: d4c3b2a1e0f9c8b7a6e5d4c3b2a1e0f9c8b7a6e5 Example when no release was made: ""
----
is_prerelease¶
Type: Literal["true", "false"]
A boolean value indicating whether the released version is a prerelease.
----
link¶
Type: string
The URL link to the release if a release was made, otherwise an empty string.
Example upon release: https://github.com/user/repo/releases/tag/v1.2.3 Example when no release was made: ""
----
previous_version¶
Type: string
The previous version before the release, if a release was or will be made. If no release is detected, this will be the current version or an empty string if no previous version exists.
----
released¶
Type: Literal["true", "false"]
A boolean value indicating whether a release was made.
----
release_notes¶
Type: string
The release notes generated by the release, if any. If no release was made, this will be an empty string.
----
version¶
Type: string
The newly released SemVer version string if one was made, otherwise the current version.
Example: 1.2.3
----
tag¶
Type: string
The Git tag corresponding to the version output but in the tag format dictated by your configuration.
Example: v1.2.3
----
Python Semantic Release Publish Action¶
The official Python Semantic Release Publish Action is a GitHub Docker Action, which means at the beginning of the job it will build a Docker image that contains the Python Semantic Release package and its dependencies. It will then run the job step inside the Docker Container. This is done to ensure that the environment is consistent across all GitHub Runners regardless of platform. With this choice, comes some limitations of non-configurable options like a pre-defined python version, lack of additional 3rd party tools, and an inability to utilize caching.
The primary benefit of using the GitHub Action is that it is easy to set up and use for most projects. We handle some additional configuration under the hood, so you don't have to handle it yourself. We do however provide a few customization options which are detailed individually below.
Most importantly your project's configuration file will be used as normal, as your project will be mounted into the container for the action to use.
If you have issues with the action, please open an issue on the python-semantic-release/publish-action repository.
SEE ALSO:
- •
- action.yml: the code definition for the publish action
Inputs¶
GitHub Action inputs are used for select configuration and provide the necessary information to execute the action. The inputs are passed to the action using the with keyword in the workflow file. Many inputs will mirror the command line options available in the publish command and others will be specific to adjustment of the action environment. This section outlines each supported input and its purpose.
----
config_file¶
Path to a custom semantic-release configuration file. By default, an empty string will look for to the pyproject.toml file in the current directory. This is the same as passing the -c or --config parameter to semantic-release.
Required: false
Default: ""
SEE ALSO:
- •
- cmd-main-option-config for the semantic-release command
----
directory¶
If the project is not at the root of the repository (like in monorepos), you can specify a sub-directory to change into before running semantic-release.
Required: false
Default: .
----
github_token¶
The GitHub Token is essential for access to your GitHub repository to allow the publish of assets to a release. Not only do you need to provide the token as an input but you also need to ensure that the token has the correct permissions.
The token should have the following permissions:
- •
- contents: write: Required for modifying a GitHub Release
Required: true
----
no_operation_mode¶
If set to true, the github action will pass the --noop parameter to semantic-release. This will cause semantic-release to run in "no operation" mode.
This is useful for testing the action without actually publishing anything.
Required: false
Default: false
SEE ALSO:
- •
- cmd-main-option-noop option for the semantic-release command
----
root_options¶
IMPORTANT:
Additional options for the main semantic-release command, which will come before the publish subcommand.
- uses: python-semantic-release/publish-action@v9
with:
root_options: "-vv --noop"
This configuration would cause the command to be semantic-release -vv --noop publish, which would run the publish command verbosely but in no-operation mode.
Required: false
Default: -v
SEE ALSO:
- •
- Options for the semantic-release command
----
tag¶
Type: string
The tag corresponding to the GitHub Release that the artifacts should be published to. This option is equivalent to running the command:
semantic-release publish --tag <tag>
Python Semantic Release will automatically determine the latest release if no --tag option is provided.
Required: false
SEE ALSO:
- •
- cmd-publish-option-tag option for the publish command
----
verbosity¶
Set the verbosity level of the output as the number of -v's to pass to semantic-release. 0 is no extra output, 1 is info level output, 2 is debug output, and 3 is a silly amount of debug output.
Required: false
Default: "1"
SEE ALSO:
- •
- cmd-main-option-verbosity for the semantic-release command
----
Outputs¶
There are no outputs provided by the Python Semantic Release Publish Action at this time.
NOTE:
----
Examples¶
Common Workflow Example¶
The following is a simple common workflow example that uses both the Python Semantic Release Action and the Python Semantic Release Publish Action. This workflow will run on every push to the main branch and will create a new release upon a successful version determination. If a version is released, the workflow will then publish the package to PyPI and upload the package to the GitHub Release Assets as well.
name: Continuous Delivery on:
push:
branches:
- main # default: least privileged permissions across all jobs permissions:
contents: read jobs:
release:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-release-${{ github.ref_name }}
cancel-in-progress: false
permissions:
contents: write
steps:
# Note: We checkout the repository at the branch that triggered the workflow
# with the entire history to ensure to match PSR's release branch detection
# and history evaluation.
# However, we forcefully reset the branch to the workflow sha because it is
# possible that the branch was updated while the workflow was running. This
# prevents accidentally releasing un-evaluated changes.
- name: Setup | Checkout Repository on Release Branch
uses: actions/checkout@v4
with:
ref: ${{ github.ref_name }}
fetch-depth: 0
- name: Setup | Force release branch to be at workflow sha
run: |
git reset --hard ${{ github.sha }}
- name: Evaluate | Verify upstream has NOT changed
# Last chance to abort before causing an error as another PR/push was applied to
# the upstream branch while this workflow was running. This is important
# because we are committing a version change (--commit). You may omit this step
# if you have 'commit: false' in your configuration.
#
# You may consider moving this to a repo script and call it from this step instead
# of writing it in-line.
shell: bash
run: |
set +o pipefail
UPSTREAM_BRANCH_NAME="$(git status -sb | head -n 1 | awk -F '\\.\\.\\.' '{print $2}' | cut -d ' ' -f1)"
printf '%s\n' "Upstream branch name: $UPSTREAM_BRANCH_NAME"
set -o pipefail
if [ -z "$UPSTREAM_BRANCH_NAME" ]; then
printf >&2 '%s\n' "::error::Unable to determine upstream branch name!"
exit 1
fi
git fetch "${UPSTREAM_BRANCH_NAME%%/*}"
if ! UPSTREAM_SHA="$(git rev-parse "$UPSTREAM_BRANCH_NAME")"; then
printf >&2 '%s\n' "::error::Unable to determine upstream branch sha!"
exit 1
fi
HEAD_SHA="$(git rev-parse HEAD)"
if [ "$HEAD_SHA" != "$UPSTREAM_SHA" ]; then
printf >&2 '%s\n' "[HEAD SHA] $HEAD_SHA != $UPSTREAM_SHA [UPSTREAM SHA]"
printf >&2 '%s\n' "::error::Upstream has changed, aborting release..."
exit 1
fi
printf '%s\n' "Verified upstream branch has not changed, continuing with release..."
- name: Action | Semantic Version Release
id: release
# Adjust tag with desired version if applicable.
uses: python-semantic-release/python-semantic-release@v10.4.1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
git_committer_name: "github-actions"
git_committer_email: "actions@users.noreply.github.com"
- name: Publish | Upload to GitHub Release Assets
uses: python-semantic-release/publish-action@v10.4.1
if: steps.release.outputs.released == 'true'
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
tag: ${{ steps.release.outputs.tag }}
- name: Upload | Distribution Artifacts
uses: actions/upload-artifact@v4
with:
name: distribution-artifacts
path: dist
if-no-files-found: error
deploy:
# 1. Separate out the deploy step from the publish step to run each step at
# the least amount of token privilege
# 2. Also, deployments can fail, and its better to have a separate job if you need to retry
# and it won't require reversing the release.
runs-on: ubuntu-latest
needs: release
if: ${{ needs.release.outputs.released == 'true' }}
permissions:
contents: read
id-token: write
steps:
- name: Setup | Download Build Artifacts
uses: actions/download-artifact@v4
id: artifact-download
with:
name: distribution-artifacts
path: dist
# ------------------------------------------------------------------- #
# Python Semantic Release is not responsible for publishing your #
# python artifacts to PyPI. Use the official PyPA publish action #
# instead. The following steps are an example but is not guaranteed #
# to work as the action is not maintained by the #
# python-semantic-release team. #
# ------------------------------------------------------------------- #
# see https://docs.pypi.org/trusted-publishers/
- name: Publish package distributions to PyPI
uses: pypa/gh-action-pypi-publish@@SHA1_HASH # vX.X.X
with:
packages-dir: dist
print-hash: true
verbose: true
IMPORTANT:
Secondly the Evaluate | Verify upstream has NOT changed step is used to ensure that the upstream branch has not changed while the workflow was running. This is important because we are committing a version change (commit: true) and there might be a push collision that would cause undesired behavior. Review Issue #1201 for more detailed information.
WARNING:
WARNING:
You can work around this by storing an administrator's Personal Access Token as a separate secret and using that instead of GITHUB_TOKEN. In this case, you will also need to pass the new token to actions/checkout (as the token input) in order to gain push access.
Version Overrides Example¶
In the case where you want to provide multiple command line options to the version command, you provide them through the with directive in the workflow file. In this example, we want to force a patch version bump, not produce a changelog, and provide specialized build metadata. As a regular CLI command, this would look like:
semantic-release version --patch --no-changelog --build-metadata abc123
The equivalent GitHub Action configuration would be:
# snippet - name: Action | Semantic Version Release
# Adjust tag with desired version if applicable.
uses: python-semantic-release/python-semantic-release@v10.4.1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
force: patch
changelog: false
build_metadata: abc123
SEE ALSO:
- •
- Publish Action Manual Release Workflow: To maintain the Publish Action at the same version as Python Semantic Release, we use a Manual release workflow which forces the matching bump type as the root project. Check out this workflow to see how you can manually provide input that triggers the desired version bump.
Actions with Monorepos¶
While python-semantic-release does NOT have full monorepo support, if you have multiple projects stored within a single repository (or your project is not at the root of the repository), you can pass the directory input to the action to change directory before semantic-release execution.
For multiple packages, you would need to run the action multiple times, to release each project. The following example demonstrates how to release two projects in a monorepo.
Remember that for each release of each submodule you will then need to handle publishing each package separately as well. This is dependent on the result of your build commands. In the example below, we assume a simple build module command to build a sdist and wheel artifacts into the submodule's dist directory.
The directory input directive is also available for the Python Semantic Release Publish Action.
jobs:
release:
env:
SUBMODULE_1_DIR: project1
SUBMODULE_2_DIR: project2
steps:
# ------------------------------------------------------------------- #
# Note the use of different IDs to distinguish which submodule was #
# identified to be released. The subsequent actions then reference #
# their specific release ID to determine if a release occurred. #
# ------------------------------------------------------------------- #
- name: Release submodule 1
id: release-submod-1
uses: python-semantic-release/python-semantic-release@v10.4.1
with:
directory: ${{ env.SUBMODULE_1_DIR }}
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Release submodule 2
id: release-submod-2
uses: python-semantic-release/python-semantic-release@v10.4.1
with:
directory: ${{ env.SUBMODULE_2_DIR }}
github_token: ${{ secrets.GITHUB_TOKEN }}
# ------------------------------------------------------------------- #
# For each submodule, you will have to publish the package separately #
# and only attempt to publish if the release for that submodule was #
# deemed a release (and the release was successful). #
# ------------------------------------------------------------------- #
- name: Publish | Upload package 1 to GitHub Release Assets
uses: python-semantic-release/publish-action@v10.4.1
if: steps.release-submod-1.outputs.released == 'true'
with:
directory: ${{ env.SUBMODULE_1_DIR }}
github_token: ${{ secrets.GITHUB_TOKEN }}
tag: ${{ steps.release-submod-1.outputs.tag }}
- name: Publish | Upload package 2 to GitHub Release Assets
uses: python-semantic-release/publish-action@v10.4.1
if: steps.release-submod-2.outputs.released == 'true'
with:
directory: ${{ env.SUBMODULE_2_DIR }}
github_token: ${{ secrets.GITHUB_TOKEN }}
tag: ${{ steps.release-submod-2.outputs.tag }}
# ------------------------------------------------------------------- #
# Python Semantic Release is not responsible for publishing your #
# python artifacts to PyPI. Use the official PyPA publish action #
# instead. The following steps are an example but is not guaranteed #
# to work as the action is not maintained by the #
# python-semantic-release team. #
# ------------------------------------------------------------------- #
- name: Publish | Upload package 1 to PyPI
uses: pypa/gh-action-pypi-publish@SHA1_HASH # vX.X.X
if: steps.release-submod-1.outputs.released == 'true'
with:
packages-dir: ${{ format('{}/dist', env.SUBMODULE_1_DIR) }}
- name: Publish | Upload package 2 to PyPI
uses: pypa/gh-action-pypi-publish@SHA1_HASH # vX.X.X
if: steps.release-submod-2.outputs.released == 'true'
with:
packages-dir: ${{ format('{}/dist', env.SUBMODULE_2_DIR) }}
Cron Job Publishing¶
This is for you if for some reason you cannot publish from your CI or you would like releases to drop at a certain interval. Before you start, answer this: Are you sure you do not want a CI to release for you? (high version numbers are not a bad thing).
The guide below is for setting up scheduled publishing on a server. It requires that the user that runs the cronjob has push access to the repository and upload access to an artifact repository.
- 1.
- Create a virtualenv:
virtualenv semantic_release -p `which python3`
- 2.
- Install python-semantic-release:
pip install python-semantic-release
3. Clone the repositories you want to have scheduled publishing. 3. Put the following in publish:
VENV=semantic_release/bin
$VENV/pip install -U pip python-semantic-release > /dev/null
publish() {
cd $1
git stash -u # ensures that there is no untracked files in the directory
git fetch && git reset --hard origin/master
$VENV/semantic-release version && $VENV/semantic-release publish
cd ..
}
publish <package1>
publish <package2>
- 4.
- Add cronjob:
/bin/bash -c "cd <path> && source semantic_release/bin/activate && ./publish 2>&1 >> releases.log"
Upgrading PSR¶
Upgrading PSR is a process that may involve several steps, depending on the version you are upgrading from and to. This section provides a guide for upgrading from older versions of PSR to the latest version.
IMPORTANT:
For example, if you are upgrading from v7 to v10, you should first upgrade to v8 and then to v9, and then lastly to v10 while following the upgrade guide for each version. At each step you should confirm execution works as expected before proceeding to the next version.
Upgrading to v10¶
The upgrade to v10 is primarily motivated by a command injection security vulnerability found in the GitHub Actions configuration interpreter (see details below). We also bundled a number of other changes, including new default configuration values and most importantly, a return to 1-line commit subjects in the default changelog format.
For more specific change details for v10, please refer to the v10.0.0 (2025-05-25) section of the CHANGELOG.
Security Fix: Command Injection Vulnerability (GitHub Actions)¶
In the previous versions of the GitHub Actions configuration, we used a single root_options parameter to pass any options you wanted to pass to the semantic-release main command. This parameter was interpreted as a string and passed directly to the command line, which made it vulnerable to command injection attacks. An attacker could exploit this by crafting a malicious string as the root_options input, and then it would be executed as part of the command line, potentially allowing them to run arbitrary commands within the GitHub Actions Docker container. The ability to exploit this vulnerability is limited to people whom can modify the GitHub Actions workflow file, which is typically only the repository maintainers unless you are pointing at an organizational workflow file or another third-party workflow file.
To mitigate this vulnerability, we have removed the root_options parameter completely and replaced it with individual boolean flag inputs which are then used to select the proper cli parameters for the semantic-release command. Additionally, users can protect themselves by limiting the access to secrets in their GitHub Actions workflows and the permissions of the GitHub Actions CI TOKEN.
This vulnerability existed in both the python-semantic-release/python-semantic-release and python-semantic-release/publish-action actions.
For the main python-semantic-release/python-semantic-release action, the following inputs are now available (in place of the old root_options parameter): config_file, no_operation_mode, strict, and verbosity.
If you previously had the following in your GitHub Actions workflow file:
- uses: python-semantic-release/python-semantic-release@v9
with:
root_options: "-vv --strict"
It would be updated to:
- uses: python-semantic-release/python-semantic-release@v10
with:
strict: true
verbosity: 2
For the python-semantic-release/publish-action action, the following inputs are now available (in place of the old root_options parameter): config_file, no_operation_mode, and verbosity.
If you previously had the following in your GitHub Actions workflow file:
- uses: python-semantic-release/publish-action@v9
with:
root_options: "-v -c /path/to/releaserc.yaml"
It would be updated to:
- uses: python-semantic-release/publish-action@v10
with:
config_file: /path/to/releaserc.yaml
verbosity: 1
Changelog Format: 1-Line Commit Subjects¶
In v10, the default changelog format has been changed to use 1-line commit subjects instead of including the full commit message. This change was made to improve the readability of the changelog as many commit messages are long and contain unnecessary details for the changelog.
IMPORTANT:
If you do not enable parse_squash_commits, then version will only be determined by the commit subject line and the changelog will only include the commit subject line as well.
Changelog Format: Mask Initial Release¶
In v10, the default behavior for the changelog generation has been changed to mask the initial release in the changelog. This means that the first release will not contain a break down of the different types of changes (e.g., features, fixes, etc.), but instead it will just simply state that this is the initial release.
Changelog Format: Commit Parsing¶
We have made some minor changes to the commit parsing logic in v10 to separate out components of the commit message more clearly. You will find that the ParsedCommit object's descriptions list will no longer contain any Breaking Change footers, Release Notice footers, PR/MR references, or Issue Closure footers. These were all previously extracted and placed into their own attributes but were still included in the descriptions list. In v10, the descriptions list will only contain the actual commit subject line and any additional commit body text that is not part of the pre-defined footers.
If you were relying on the descriptions list to contain these footers, you will need to update your code and changelog templates to reference the specific attributes you want to use.
Default Configuration Changes¶
The following table summarizes the changes to the default configuration values in v10:
| # | Configuration Option | Previous Default Value | New Default Value |
| 1 | allow_zero_version | true | false |
| 2 | changelog.mode | init | update |
| 3 | changelog.default_templates.mask_initial_release | false | true |
| 4 | commit_parser_options.parse_squash_commits | false | true |
| 5 | commit_parser_options.ignore_merge_commits | false | true |
Deprecations & Removals¶
No additional deprecations were made in v10, but the following are staged for removal in v11:
Deprecated Features & Functions¶
| # | Component | Deprecated | Planned Removal | Notes |
| 1 | GitHub Actions root_options | v10.0.0 | v10.0.0 | Replaced with individual boolean flag inputs. See above for details. |
| 2 | Angular Commit Parser | v9.19.0 | v11.0.0 | Replaced by the Conventional Commit Parser. |
| 3 | Tag Commit Parser | v9.12.0 | v11.0.0 | Replaced by the Emoji Commit Parser. |
NOTE:
Upgrading to v9¶
You are in luck! The upgrade to v9 is a simple one.
The breaking change for this version is the removal of support for Python 3.7, as it has passed End-Of-Life (EOL). This means that if you are using Python 3.7, you will need to upgrade to at least Python 3.8 in order to use v9. This will be permanent as all future versions of python-semantic-release will require Python 3.8 or later.
Upgrading to v8¶
Python Semantic Release v8.0.0 introduced a number of breaking changes. The internals have been changed significantly to better support highly-requested features and to streamline the maintenance of the project.
As a result, certain things have been removed, reimplemented differently, or now exhibit different behavior to earlier versions of Python Semantic Release. This page is a guide to help projects to pip install python-semantic-release>=8.0.0 with fewer surprises.
Python Semantic Release GitHub Action¶
GitHub Action no longer publishes artifacts to PyPI or GitHub Releases¶
Python Semantic Release no longer uploads distributions to PyPI - see Repurposing of version and publish commands. If you are using Python Semantic Release to publish release notes and artifacts to GitHub releases, there is a new GitHub Action upload-to-gh-release which will perform this action for you.
This means the following workflows perform the same actions, and if you are using the former, you will need to modify your workflow to include the steps in the latter.
This workflow is written to use Python Semantic Release v7.33.5:
--- name: Semantic Release on:
push:
branches:
- main jobs:
release:
runs-on: ubuntu-latest
concurrency: release
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
# This action uses Python Semantic Release v7
- name: Python Semantic Release
uses: python-semantic-release/python-semantic-release@v7.33.5
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
repository_username: __token__
repository_password: ${{ secrets.PYPI_TOKEN }}
The following workflow achieves the same result using Python Semantic Release v8, the upload-to-gh-release GitHub Action, and the pypa/gh-action-pypi-publish GitHub Action:
--- name: Semantic Release on:
push:
branches:
- main jobs:
release:
runs-on: ubuntu-latest
concurrency: release
permissions:
id-token: write
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
# This action uses Python Semantic Release v8
- name: Python Semantic Release
id: release
uses: python-semantic-release/python-semantic-release@v8.7.0
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Publish package distributions to PyPI
uses: pypa/gh-action-pypi-publish@v1
# NOTE: DO NOT wrap the conditional in ${{ }} as it will always evaluate to true.
# See https://github.com/actions/runner/issues/1173
if: steps.release.outputs.released == 'true'
- name: Publish package distributions to GitHub Releases
uses: python-semantic-release/upload-to-gh-release@v8.7.0
if: steps.release.outputs.released == 'true'
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
Removal of pypi_token, repository_username and repository_password inputs¶
Since the library no longer supports publishing to PyPI, the pypi_token, repository_username and repository_password inputs of the GitHub action have all been removed. See the above section for how to publish to PyPI using the official GitHub Action from the Python Packaging Authority (PyPA).
Rename additional_options to root_options¶
Because the purposes of the cmd-version and cmd-publish commands have changed, the GitHub action now performs both commands in sequence. For this reason, and because the usage of the CLI has changed, additional_options has been renamed to root_options to reflect the fact that the options are for the main cmd-main command group.
Commands¶
Repurposing of version and publish commands¶
Python Semantic Release's primary purpose is to enable automation of correct semantic versioning for software projects. Over the years, this automation has been extended to include other actions such as building/publishing the project and its artifacts to artefact repositories, creating releases in remote version control systems, and writing changelogs.
In Python Semantic Release <8.0.0, the publish command was a one-stop-shop for performing every piece of automation provided. This has been changed - the version command now handles determining the next version, applying the changes to the project metadata according to the configuration, writing a changelog, and committing/pushing changes to the remote Git repository. It also handles creating a release in the remote VCS. It does not publish software artifacts to remote repositories such as PyPI; the rationale behind this decision is simply that under the hood, Python Semantic Release used twine to upload artifacts to package indexes such as PyPI, and it's recommended to use twine directly via the command-line. From the twine documentation:
As a result Python Semantic Release no longer depends on twine internals.
The publish command now handles publishing software artifacts to releases in the remote version control system.
To achieve a similar flow of logic such as
- 1.
- Determine the next version
- 2.
- Write this version to the configured metadata locations
- 3.
- Write the changelog
- 4.
- Push the changes to the metadata and changelog to the remote repository
- 5.
- Create a release in the remote version control system
- 6.
- Build a wheel
- 7.
- Publish the wheel to PyPI
- 8.
- Publish the distribution artifacts to the release in the remote VCS
You should run:
semantic-release version twine upload dist/* # or whichever path your distributions are placed in semantic-release publish
With steps 1-6 being handled by the cmd-version command, step 7 being left to the developer to handle, and lastly step 8 to be handled by the cmd-publish command.
Removal of -D/--define command-line option¶
It is no longer possible to override arbitrary configuration values using the -D/ --define option. You should provide the appropriate values via a configuration file using cmd-main-option-config or via the available command-line options.
This simplifies the command-line option parsing significantly and is less error-prone, which has resulted in previous issues (e.g. #600) with overrides on the command-line. Some of the configuration values expected by Python Semantic Release use complex data types such as lists or nested structures, which would be tedious and error-prone to specify using just command-line options.
Removal of CI verifications¶
Prior to v8, Python Semantic Release would perform some prerequisite verification of environment variables before performing any version changes using the publish command. It's not feasible for Python Semantic Release to verify any possible CI environment fully, and these checks were only triggered if certain environment variables were set - they wouldn't fail locally.
These checks previously raised :py:class:semantic_release.CiVerificationError, and were the only place in which this custom exception was used. Therefore, this exception has also been removed from Python Semantic Release in v8.
If you were relying on this functionality, it's recommended that you add the following shell commands before invoking semantic-release to verify your environment:
NOTE:
Travis¶
Condition: environment variable TRAVIS=true
Replacement:
if ! [[
$TRAVIS_BRANCH == $RELEASE_BRANCH && \
$TRAVIS_PULL_REQUEST == 'false'
]]; then
exit 1 fi
Semaphore¶
Condition: environment variable SEMAPHORE=true
Replacement:
if ! [[
$BRANCH_NAME == $RELEASE_BRANCH && \
$SEMAPHORE_THREAD_RESULT != 'failed' && \
-n $PULL_REQUEST_NUMBER
]]; then
exit 1 fi
Frigg¶
Condition: environment variable FRIGG=true
Replacement:
if ! [[
$FRIGG_BUILD_BRANCH == $RELEASE_BRANCH && \
-n $FRIGG_PULL_REQUEST
]]; then
exit 1 fi
Circle CI¶
Condition: environment variable CIRCLECI=true
Replacement:
if ! [[
$CIRCLE_BRANCH == $RELEASE_BRANCH && \
-n $CI_PULL_REQUEST
]]; then
exit 1 fi
GitLab CI¶
Condition: environment variable GITLAB_CI=true
Replacement:
if ! [[ $CI_COMMIT_REF_NAME == $RELEASE_BRANCH ]]; then
exit 1 fi
Condition: environment variable BITBUCKET_BUILD_NUMBER is set
Replacement:
if ! [[
$BITBUCKET_BRANCH == $RELEASE_BRANCH && \
-n $BITBUCKET_PR_ID
]]; then
exit 1 fi
Jenkins¶
Condition: environment variable JENKINS_URL is set
Replacement:
if [[ -z $BRANCH_NAME ]]; then
BRANCH_NAME=$BRANCH_NAME elif [[ -z $GIT_BRANCH ]]; then
BRANCH_NAME=$GIT_BRANCH fi if ! [[
$BRANCH_NAME == $RELEASE_BRANCH && \
-n $CHANGE_ID
]]; then
exit 1 fi
Removal of Build Status Checking¶
Prior to v8, Python Semantic Release contained a configuration option, check_build_status, which would attempt to prevent a release being made if it was possible to identify that a corresponding build pipeline was failing. For similar reasons to those motivating the removal of CI Checks, this feature has also been removed.
If you are leveraging this feature in Python Semantic Release v7, the following bash commands will replace the functionality, and you can add these to your pipeline. You will need to install jq and curl to run these commands; they can be easily installed through your system's package manager, for example on Ubuntu:
sudo apt update && sudo apt upgrade sudo apt install -y curl jq
On Windows, you can refer to the installation guide for jq, and if curl is not already installed, you can download it from the curl website
GitHub¶
export RESP="$(
curl \
-H "Authorization: token $GITHUB_TOKEN" \
-fSsL https://$GITHUB_API_DOMAIN/repos/$REPO_OWNER/$REPO_NAME/commits/$(git rev-parse HEAD)/status || exit 1 )" if [ $(jq -r '.state' <<< "$RESP") != "success" ]; then
echo "Build status is not success" >&2
exit 1 fi
Note that $GITHUB_API_DOMAIN is typically api.github.com unless you are using GitHub Enterprise with a custom domain name.
Gitea¶
export RESP="$(
curl \
-H "Authorization: token $GITEA_TOKEN" \
-fSsL https://$GITEA_DOMAIN/repos/$REPO_OWNER/$REPO_NAME/statuses/$(git rev-parse HEAD) || exit 1 )" if [ $(jq -r '.state' <<< "$RESP") != "success" ]; then
echo "Build status is not success" >&2
exit 1 fi
Gitlab¶
export RESP="$(
curl \
-H "Authorization: token $GITLAB_TOKEN" \
-fSsL https://$GITLAB_DOMAIN/api/v4/projects/$PROJECT_ID/repository/commits/$(git rev-parse HEAD)/statuses
)"
for line in $(jq -r '.[] | [.name, .status, .allow_failure] | join("|")' <<<"$RESP"); do
IFS="|" read -r job_name job_status allow_failure <<<"$line"
if [ "$job_status" == "pending" ]; then
echo "job $job_name is pending" >&2
exit 1
elif [ "$job_status" == "failed" ] && [ ! "$allow_failure" == "true" ]; then
echo "job $job_name failed" >&2
exit 1
fi done
Multibranch releases¶
Prior to v8, Python Semantic Release would perform git checkout to switch to your configured release branch and determine if a release would need to be made. In v8 this has been changed - you must manually check out the branch which you would like to release against, and if you would like to create releases against this branch you must also ensure that it belongs to a release group.
changelog command¶
A new option, cmd-changelog-option-post-to-release-tag has been added. If you omit this argument on the command line then the changelog rendering process, which is described in more detail at Custom Changelogs, will be triggered, but the new changelog will not be posted to any release. If you use this new command-line option, it should be set to a tag within the remote which has a corresponding release. For example, to update the changelog and post it to the release corresponding to the tag v1.1.4, you should run:
semantic-release changelog --post-to-release-tag v1.1.4
Changelog customization¶
A number of options relevant to customizing the changelog have been removed. This is because Python Semantic Release now supports authoring a completely custom Jinja template with the contents of your changelog. Historically, the number of options added to Python Semantic Release in order to allow this customization has grown significantly; it now uses templates in order to fully open up customizing the changelog's appearance.
Configuration¶
The configuration structure has been completely reworked, so you should read Configuration carefully during the process of upgrading to v8+. However, some common pitfalls and potential sources of confusion are summarized here.
setup.cfg is no longer supported¶
Python Semantic Release no longer supports configuration via setup.cfg. This is because the Python ecosystem is centering around pyproject.toml as universal tool and project configuration file, and TOML allows expressions via configuration, such as the mechanism for declaring configuration via environment variables, which introduce much greater complexity to support in the otherwise equivalent ini-format configuration.
You can use cmd-generate-config to generate new-format configuration that can be added to pyproject.toml, and adjust the default settings according to your needs.
WARNING:
More detail about this issue can be found in this pip issue.
Commit parser options¶
Options such as major_emoji, parser_angular_patch_types or parser_angular_default_level_bump have been removed. Instead, these have been replaced with a single set of recognized commit parser options, allowed_tags, major_tags, minor_tags, and patch_tags, though the interpretation of these is up to the specific parsers in use. You can read more detail about using commit parser options in commit_parser_options, and if you need to parse multiple commit styles for a single project it's recommended that you create a parser following Custom Parsers that is tailored to the specific needs of your project.
version_variable¶
This option has been renamed to version_variables as it refers to a list of variables which can be updated.
version_pattern¶
This option has been removed. It's recommended to use an alternative tool to perform substitution using arbitrary regular expressions, such as sed. You can always use Python Semantic Release to identify the next version to be created for a project and store this in an environment variable like so:
export VERSION=$(semantic-release version --print)
version_toml¶
This option will no longer accept a string or comma-separated string of version locations to be updated in TOML files. Instead, you must supply a List[str]. For existing configurations using a single location in this option, you can simply wrap the value in []:
# Python Semantic Release v7 configuration [tool.semantic_release] version_toml = "pyproject.toml:tool.poetry.version" # Python Semantic Release v8 configuration [tool.semantic_release] version_toml = ["pyproject.toml:tool.poetry.version"]
tag_format¶
This option has the same effect as it did in Python Semantic Release prior to v8, but Python Semantic Release will now verify that it has a {version} format key and raise an error if this is not the case.
upload_to_release¶
This option has been renamed to upload_to_vcs_release.
Custom Commit Parsers¶
Previously, a custom commit parser had to satisfy the following criteria:
- It should be import-able from the virtual environment where the semantic-release is run
- It should be a function which accepts the commit message as its only argument and returns a semantic_release.history.parser_helpers.ParsedCommit if the commit is parsed successfully, or raise a semantic_release.UnknownCommitMessageStyleError if parsing is unsuccessful.
It is still possible to implement custom commit parsers, but the interface for doing so has been modified with stronger support for Python type annotations and broader input provided to the parser to enable capturing more information from each commit, such as the commit's date and author, if desired. A full guide to implementing a custom commit parser can be found at Custom Parsers.
Troubleshooting¶
- Check your configuration file for Configuration
- Check your Git tags match your tag_format; tags using other formats are ignored during calculation of the next version.
Increasing Verbosity¶
If you are having trouble with Python Semantic Release or would like to see additional information about the actions that it is taking, you can use the top-level cmd-main-option-verbosity option. This can be supplied multiple times to increase the logging verbosity of the cmd-main command or any of its subcommands during their execution. You can supply this as many times as you like, but supplying more than twice has no effect.
Supply cmd-main-option-verbosity once for INFO output, and twice for DEBUG.
For example:
semantic-release -vv version --print
NOTE:
WARNING:
NOTE:
src¶
semantic_release package¶
Python Semantic Release
- semantic_release.setup_hook(argv: list[str]) -> None
- A hook to be used in setup.py to enable python setup.py publish.
- Parameters
- argv -- sys.argv
Subpackages¶
semantic_release.changelog package¶
Submodules¶
semantic_release.changelog.context module¶
- semantic_release.changelog.context.autofit_text_width(text: str, maxwidth: int = 100, indent_size: int = 0) -> str
- Format the description text to fit within a specified width
semantic_release.changelog.release_history module¶
semantic_release.changelog.template module¶
- class semantic_release.changelog.template.ComplexDirectorySandboxedEnvironment(*args: Any, **kwargs: Any)
- Bases: SandboxedEnvironment
- join_path(template: str, parent: str) -> str
- Add support for complex directory structures in the template directory.
This method overrides the default functionality of the SandboxedEnvironment where all 'include' keywords expect to be in the same directory as the calling template, however this is unintuitive when using a complex directory structure.
This override simulates the changing of directories when you include the template from a child directory. When the child then includes a template, it will make the path relative to the child directory rather than the top level template directory.
- semantic_release.changelog.template.environment(template_dir: Path | str = '.', block_start_string: str = '{%', block_end_string: str = '%}', variable_start_string: str = '{{', variable_end_string: str = '}}', comment_start_string: str = '{#', comment_end_string: str = '#}', line_statement_prefix: str | None = None, line_comment_prefix: str | None = None, trim_blocks: bool = False, lstrip_blocks: bool = False, newline_sequence: Literal['\n', '\r', '\r\n'] = '\n', keep_trailing_newline: bool = False, extensions: Iterable[str] = (), autoescape: bool | str = True) -> SandboxedEnvironment
- Create a jinja2.sandbox.SandboxedEnvironment with certain parameter
resrictions.
For example the Loader is fixed to FileSystemLoader, although the searchpath is configurable.
autoescape can be a string in which case it should follow the convention module:attr, in this instance it will be dynamically imported. See https://jinja.palletsprojects.com/en/3.1.x/api/#jinja2.Environment for full parameter descriptions
semantic_release.cli package¶
Subpackages¶
semantic_release.cli.commands package¶
Submodules¶
semantic_release.cli.commands.changelog module¶
semantic_release.cli.commands.generate_config module¶
semantic_release.cli.commands.main module¶
- class semantic_release.cli.commands.main.Cli(name: str | None = None, invoke_without_command: bool = False, no_args_is_help: bool | None = None, subcommand_metavar: str | None = None, chain: bool = False, result_callback: Callable[[...], Any] | None = None, **attrs: Any)
- Bases: MultiCommand
Root MultiCommand for the semantic-release CLI
- class SubCmds(*values)
- Bases: Enum
Subcommand import definitions
- CHANGELOG = 'semantic_release.cli.commands.changelog'
- get_command(_ctx: Context, name: str) -> Command | None
- Given a context and a command name, this returns a Command object if it exists or returns None.
- list_commands(_ctx: Context) -> list[str]
- Returns a list of subcommand names in the order they should appear.
semantic_release.cli.commands.publish module¶
semantic_release.cli.commands.version module¶
- semantic_release.cli.commands.version.build_distributions(build_command: str | None, build_command_env: Mapping[str, str] | None = None, noop: bool = False) -> None
- Run the build command to build the distributions.
- build_command -- The build command to run.
- build_command_env -- The environment variables to use when running the build command.
- noop -- Whether or not to run the build command.
- Raises
- BuildDistributionsError: if the build command fails
- semantic_release.cli.commands.version.is_forced_prerelease(as_prerelease: bool, forced_level_bump: LevelBump | None, prerelease: bool) -> bool
- Determine if this release is forced to have prerelease on/off. If force_prerelease is set then yes. Otherwise if we are forcing a specific level bump without force_prerelease, it's False. Otherwise (force_level is None) use the value of prerelease
Submodules¶
semantic_release.cli.changelog_writer module¶
semantic_release.cli.cli_context module¶
- property runtime_ctx: RuntimeContext
- Lazy load the runtime context. This is done to avoid configuration loading when the command is not run. This is useful for commands like --help and --version
semantic_release.cli.config module¶
- class semantic_release.cli.config.BranchConfig(*, match: str = '(main|master)', prerelease_token: str = 'rc', prerelease: bool = False)
- Bases: BaseModel
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
- changelog_file: str
- Deprecated! Moved to 'default_templates.changelog_file'
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
- class semantic_release.cli.config.ChangelogOutputFormat(*values)
- Bases: str, Enum
Supported changelog output formats when using the default templates.
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
- class semantic_release.cli.config.EnvConfigVar(*, env: str, default: str | None = None, default_env: str | None = None)
- Bases: BaseModel
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
- class semantic_release.cli.config.GlobalCommandLineOptions(noop: bool = False, verbosity: int = 0, config_file: str = 'pyproject.toml', strict: bool = False)
- Bases: object
A dataclass to hold all the command line options that should be set in the RuntimeContext
- class semantic_release.cli.config.PublishConfig(*, dist_glob_patterns: Tuple[str, ...] = ('dist/*',), upload_to_vcs_release: bool = True)
- Bases: BaseModel
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
- model_config: ClassVar[ConfigDict] = {}
- Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].
semantic_release.cli.const module¶
semantic_release.cli.github_actions_output module¶
semantic_release.cli.masking_filter module¶
- filter(record: LogRecord) -> bool
- Determine if the specified record is to be logged.
Returns True if the record should be logged, or False otherwise. If deemed appropriate, the record may be modified in-place.
semantic_release.cli.util module¶
Utilities for command-line functionality
- semantic_release.cli.util.indented(msg: str, prefix: str = ' ') -> str
- Convenience function for text-formatting for the console.
Ensures the least indented line of the msg string is indented by prefix with consistent alignment of the remainder of msg irrespective of the level of indentation in the Python source code
- semantic_release.cli.util.load_raw_config_file(config_file: Path | str) -> dict[Any, Any]
- Load raw configuration as a dict from the filename specified by config_filename, trying the following parsing methods:
- 1.
- try to parse with tomli.load (guessing it's a TOML file)
- 2.
- try to parse with json.load (guessing it's a JSON file)
- 3.
- raise InvalidConfiguration if none of the above parsing methods work
This function will also raise FileNotFoundError if it is raised while trying to read the specified configuration file
- semantic_release.cli.util.noop_report(msg: str) -> None
- Rich-prints a msg with a standard prefix to report when an action is not being taken due to a "noop" flag
- semantic_release.cli.util.parse_toml(raw_text: str) -> dict[Any, Any]
- Attempts to parse raw configuration for semantic_release using tomlkit.loads, raising InvalidConfiguration if the TOML is invalid or there's no top level "semantic_release" or "tool.semantic_release" keys
- semantic_release.cli.util.rprint(msg: str) -> None
- Rich-prints to stderr so that redirection of command output isn't cluttered
semantic_release.commit_parser package¶
Subpackages¶
semantic_release.commit_parser.conventional package¶
Submodules¶
semantic_release.commit_parser.conventional.options module¶
- class semantic_release.commit_parser.conventional.options.ConventionalCommitParserOptions(minor_tags: Tuple[str, ...] = ('feat',), patch_tags: Tuple[str, ...] = ('fix', 'perf'), other_allowed_tags: Tuple[str, ...] = ('build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), allowed_tags: Tuple[str, ...] = ('feat', 'fix', 'perf', 'build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), default_bump_level: LevelBump = LevelBump.NO_RELEASE, parse_squash_commits: bool = True, ignore_merge_commits: bool = True)
- Bases: ParserOptions
Options dataclass for the ConventionalCommitParser.
- All commit-type prefixes that are allowed.
These are used to identify a valid commit message. If a commit message does not start with one of these prefixes, it will not be considered a valid commit message.
- default_bump_level: LevelBump = 0
- The minimum bump level to apply to valid commit message.
- ignore_merge_commits: bool = True
- Toggle flag for whether or not to ignore merge commits
- Commit-type prefixes that should result in a minor release bump.
- Commit-type prefixes that are allowed but do not result in a version bump.
- parse_squash_commits: bool = True
- Toggle flag for whether or not to parse squash commits
- Commit-type prefixes that should result in a patch release bump.
- property tag_to_level: dict[str, LevelBump]
- A mapping of commit tags to the level bump they should result in.
semantic_release.commit_parser.conventional.options_monorepo module¶
- class semantic_release.commit_parser.conventional.options_monorepo.ConventionalCommitMonorepoParserOptions(minor_tags: Tuple[str, ...] = ('feat',), patch_tags: Tuple[str, ...] = ('fix', 'perf'), other_allowed_tags: Tuple[str, ...] = ('build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), allowed_tags: Tuple[str, ...] = ('feat', 'fix', 'perf', 'build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), default_bump_level: LevelBump = LevelBump.NO_RELEASE, parse_squash_commits: bool = True, ignore_merge_commits: bool = True, path_filters: Annotated[Tuple[str, ...], Field(validate_default=True)] = ('.',), scope_prefix: str = '')
- Bases: ConventionalCommitParserOptions
Options dataclass for ConventionalCommitMonorepoParser.
- classmethod convert_strs_to_paths()
- Wrap a classmethod, staticmethod, property or unbound function and act as
a descriptor that allows us to detect decorated items from the class'
attributes.
This class' __get__ returns the wrapped item's __get__ result, which makes it transparent for classmethods and staticmethods.
- Attributes:
- wrapped: The decorator that has to be wrapped. decorator_info: The decorator info. shim: A wrapper function to wrap V1 style function.
- path_filters: Annotated[Tuple[str, ...], Field(validate_default=True)] = ('.',)
- A set of relative paths to filter commits by. Only commits with file
changes that match these file paths or its subdirectories will be
considered valid commits.
Syntax is similar to .gitignore with file path globs and inverse file match globs via ! prefix. Paths should be relative to the current working directory.
- classmethod resolve_path()
- Wrap a classmethod, staticmethod, property or unbound function and act as
a descriptor that allows us to detect decorated items from the class'
attributes.
This class' __get__ returns the wrapped item's __get__ result, which makes it transparent for classmethods and staticmethods.
- Attributes:
- wrapped: The decorator that has to be wrapped. decorator_info: The decorator info. shim: A wrapper function to wrap V1 style function.
- scope_prefix: str = ''
- A prefix that will be striped from the scope when parsing commit messages.
If set, it will cause unscoped commits to be ignored. Use this in tandem with the path_filters option to filter commits by directory and scope. This will be fed into a regular expression so you must escape any special characters that are meaningful in regular expressions (e.g. ., *, ?, +, etc.) if you want to match them literally.
- classmethod validate_scope_prefix()
- Wrap a classmethod, staticmethod, property or unbound function and act as
a descriptor that allows us to detect decorated items from the class'
attributes.
This class' __get__ returns the wrapped item's __get__ result, which makes it transparent for classmethods and staticmethods.
- Attributes:
- wrapped: The decorator that has to be wrapped. decorator_info: The decorator info. shim: A wrapper function to wrap V1 style function.
semantic_release.commit_parser.conventional.parser module¶
- class semantic_release.commit_parser.conventional.parser.ConventionalCommitParser(options: ConventionalCommitParserOptions | None = None)
- Bases: CommitParser[ParsedCommit | ParseError,
ConventionalCommitParserOptions]
A commit parser for projects conforming to the conventional commits specification.
- parse(commit: Commit) -> ParsedCommit | ParseError | list[ParsedCommit | ParseError]
- Parse a commit message
If the commit message is a squashed merge commit, it will be split into multiple commits, each of which will be parsed separately. Single commits will be returned as a list of a single ParseResult.
- parser_options
- alias of ConventionalCommitParserOptions
semantic_release.commit_parser.conventional.parser_monorepo module¶
- class semantic_release.commit_parser.conventional.parser_monorepo.ConventionalCommitMonorepoParser(options: ConventionalCommitMonorepoParserOptions | None = None)
- Bases: CommitParser[ParsedCommit | ParseError, ConventionalCommitMonorepoParserOptions]
- parse_commit(commit: Commit) -> ParseResult
- Attempt to parse the commit message with a regular expression into a ParseResult.
- parser_options
- alias of ConventionalCommitMonorepoParserOptions
Submodules¶
semantic_release.commit_parser.angular module¶
Angular commit style parser https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-guidelines
- class semantic_release.commit_parser.angular.AngularCommitParser(options: AngularParserOptions | None = None)
- Bases: CommitParser[ParsedCommit | ParseError,
AngularParserOptions]
A commit parser for projects conforming to the angular style of conventional commits. See https://www.conventionalcommits.org/en/v1.0.0-beta.4/
- parse(commit: Commit) -> ParsedCommit | ParseError | list[ParsedCommit | ParseError]
- Parse a commit message
If the commit message is a squashed merge commit, it will be split into multiple commits, each of which will be parsed separately. Single commits will be returned as a list of a single ParseResult.
- parser_options
- alias of AngularParserOptions
- class semantic_release.commit_parser.angular.AngularParserOptions(minor_tags: Tuple[str, ...] = ('feat',), patch_tags: Tuple[str, ...] = ('fix', 'perf'), other_allowed_tags: Tuple[str, ...] = ('build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), allowed_tags: Tuple[str, ...] = ('feat', 'fix', 'perf', 'build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), default_bump_level: LevelBump = LevelBump.NO_RELEASE, parse_squash_commits: bool = False, ignore_merge_commits: bool = False)
- Bases: ParserOptions
Options dataclass for AngularCommitParser
- All commit-type prefixes that are allowed.
These are used to identify a valid commit message. If a commit message does not start with one of these prefixes, it will not be considered a valid commit message.
- default_bump_level: LevelBump = 0
- The minimum bump level to apply to valid commit message.
- ignore_merge_commits: bool = False
- Toggle flag for whether or not to ignore merge commits
- Commit-type prefixes that should result in a minor release bump.
- Commit-type prefixes that are allowed but do not result in a version bump.
- parse_squash_commits: bool = False
- Toggle flag for whether or not to parse squash commits
- Commit-type prefixes that should result in a patch release bump.
- property tag_to_level: dict[str, LevelBump]
- A mapping of commit tags to the level bump they should result in.
semantic_release.commit_parser.emoji module¶
Commit parser which looks for emojis to determine the type of commit
- class semantic_release.commit_parser.emoji.EmojiCommitParser(options: EmojiParserOptions | None = None)
- Bases: CommitParser[ParsedCommit | ParseError,
EmojiParserOptions]
Parse a commit using an emoji in the subject line. When multiple emojis are encountered, the one with the highest bump level is used. If there are multiple emojis on the same level, the we use the one listed earliest in the configuration. If the message does not contain any known emojis, then the level to bump will be 0 and the type of change "Other". This parser never raises UnknownCommitMessageStyleError. Emojis are not removed from the description, and will appear alongside the commit subject in the changelog.
- parse(commit: Commit) -> ParsedCommit | ParseError | list[ParsedCommit | ParseError]
- Parse a commit message
If the commit message is a squashed merge commit, it will be split into multiple commits, each of which will be parsed separately. Single commits will be returned as a list of a single ParseResult.
- parser_options
- alias of EmojiParserOptions
- All commit-type prefixes that are allowed.
- default_bump_level: LevelBump = 0
- The minimum bump level to apply to valid commit message.
- ignore_merge_commits: bool = True
- Toggle flag for whether or not to ignore merge commits
- Commit-type prefixes that should result in a major release bump.
- Commit-type prefixes that should result in a minor release bump.
- Commit-type prefixes that are allowed but do not result in a version bump.
- parse_linked_issues: bool = False
- Whether to parse linked issues from the commit message.
Issue identification is not defined in the Gitmoji specification, so this parser will not attempt to parse issues by default. If enabled, the parser will use the same identification as GitHub, GitLab, and BitBucket use for linking issues, which is to look for a git commit message footer starting with "Closes:", "Fixes:", or "Resolves:" then a space, and then the issue identifier. The line prefix can be singular or plural and it is not case-sensitive but must have a colon and a whitespace separator.
- parse_squash_commits: bool = True
- Toggle flag for whether or not to parse squash commits
- Commit-type prefixes that should result in a patch release bump.
- property tag_to_level: dict[str, LevelBump]
- A mapping of commit tags to the level bump they should result in.
semantic_release.commit_parser.scipy module¶
Parses commit messages using scipy tags of the form:
<tag>(<scope>): <subject> <body>
The elements <tag>, <scope> and <body> are optional. If no tag is present, the commit will be added to the changelog section "None" and no version increment will be performed.
While <scope> is supported here it isn't actually part of the scipy style. If it is missing, parentheses around it are too. The commit should then be of the form:
<tag>: <subject> <body>
To communicate a breaking change add "BREAKING CHANGE" into the body at the beginning of a paragraph. Fill this paragraph with information how to migrate from the broken behavior to the new behavior. It will be added to the "Breaking" section of the changelog.
Supported Tags:
(
API,
DEP,
ENH,
REV,
BUG,
MAINT,
BENCH,
BLD, ) DEV, DOC, STY, TST, REL, FEAT, TEST
Supported Changelog Sections:
breaking, feature, fix, Other, None
- class semantic_release.commit_parser.scipy.ScipyCommitParser(options: ScipyParserOptions | None = None)
- Bases: CommitParser[ParsedCommit | ParseError,
ScipyParserOptions]
Parser for scipy-style commit messages
- parse(commit: Commit) -> ParsedCommit | ParseError | list[ParsedCommit | ParseError]
- Parse a commit message
If the commit message is a squashed merge commit, it will be split into multiple commits, each of which will be parsed separately. Single commits will be returned as a list of a single ParseResult.
- parser_options
- alias of ScipyParserOptions
- class semantic_release.commit_parser.scipy.ScipyParserOptions(major_tags: Tuple[str, ...] = ('API', 'DEP'), minor_tags: Tuple[str, ...] = ('ENH', 'FEAT'), patch_tags: Tuple[str, ...] = ('BLD', 'BUG', 'MAINT'), other_allowed_tags: Tuple[str, ...] = ('DEV', 'BENCH', 'DOC', 'STY', 'TST', 'REL', 'TEST'), allowed_tags: Tuple[str, ...] = ('API', 'DEP', 'ENH', 'FEAT', 'BLD', 'BUG', 'MAINT', 'DEV', 'BENCH', 'DOC', 'STY', 'TST', 'REL', 'TEST'), default_level_bump: LevelBump = LevelBump.NO_RELEASE, parse_squash_commits: bool = True, ignore_merge_commits: bool = True)
- Bases: ParserOptions
Options dataclass for ScipyCommitParser
Scipy-style commit messages follow the same format as Angular-style commit just with different tag names.
- All commit-type prefixes that are allowed.
These are used to identify a valid commit message. If a commit message does not start with one of these prefixes, it will not be considered a valid commit message.
- default_level_bump: LevelBump = 0
- The minimum bump level to apply to valid commit message.
- ignore_merge_commits: bool = True
- Toggle flag for whether or not to ignore merge commits
- Commit-type prefixes that should result in a major release bump.
- Commit-type prefixes that should result in a minor release bump.
- Commit-type prefixes that are allowed but do not result in a version bump.
- parse_squash_commits: bool = True
- Toggle flag for whether or not to parse squash commits
- Commit-type prefixes that should result in a patch release bump.
- property tag_to_level: dict[str, LevelBump]
- A mapping of commit tags to the level bump they should result in.
semantic_release.commit_parser.tag module¶
Legacy commit parser from Python Semantic Release 1.0
- class semantic_release.commit_parser.tag.TagCommitParser(options: _OPTS | None = None)
- Bases: CommitParser[ParsedCommit | ParseError,
TagParserOptions]
Parse a commit message according to the 1.0 version of python-semantic-release. It expects a tag of some sort in the commit message and will use the rest of the first line as changelog content.
- parser_options
- alias of TagParserOptions
- class semantic_release.commit_parser.tag.TagParserOptions(minor_tag: str = ':sparkles:', patch_tag: str = ':nut_and_bolt:')
- Bases: ParserOptions
semantic_release.commit_parser.token module¶
- class semantic_release.commit_parser.token.ParseError(commit: Commit, error: str)
- Bases: NamedTuple
A read-only named tuple object representing an error that occurred while parsing a commit message.
- commit: Commit
- The original commit object (a class defined by GitPython) that was parsed
- error: str
- A string with a description for why the commit parsing failed.
- property hexsha: str
- A hex representation of the hash value of the commit.
This is a pass through property for convience to access the hexsha attribute of the commit.
- property message: str
- A string representation of the commit message.
This is a pass through property for convience to access the message attribute of the commit object.
If the message is of type bytes then it will be decoded to a UTF-8 string.
- raise_error() -> NoReturn
- A convience method to raise a CommitParseError with the error message.
- property short_hash: str
- A short representation of the hash value (in hex) of the commit.
- class semantic_release.commit_parser.token.ParsedCommit(bump: LevelBump, type: str, scope: str, descriptions: list[str], breaking_descriptions: list[str], commit: Commit, release_notices: tuple[str, ...] = (), linked_issues: tuple[str, ...] = (), linked_merge_request: str = '', include_in_changelog: bool = True)
- Bases: NamedTuple
A read-only named tuple object representing the result of parsing a commit message.
- breaking_descriptions: list[str]
- A list of paragraphs which are deemed to identify and describe breaking
changes by the parser.
An example would be a paragraph which begins with the text BREAKING CHANGE: in the commit message but the parser gennerally strips the prefix and includes the rest of the paragraph in this list.
- bump: LevelBump
- A LevelBump enum value indicating what type of change this commit introduces.
- commit: Commit
- The original commit object (a class defined by GitPython) that was parsed
- descriptions: list[str]
- A list of paragraphs from the commit message.
Paragraphs are generally delimited by a double-newline since git commit messages are sometimes manually wordwrapped with a single newline, but this is up to the parser to implement.
- static from_parsed_message_result(commit: Commit, parsed_message_result: ParsedMessageResult) -> ParsedCommit
- A convience method to create a ParsedCommit object from a ParsedMessageResult object and a Commit object.
- property hexsha: str
- A hex representation of the hash value of the commit.
This is a pass through property for convience to access the hexsha attribute of the commit.
- include_in_changelog: bool
- A boolean value indicating whether this commit should be included in the
changelog.
This enables parsers to flag commits which are not user-facing or are otherwise not relevant to the changelog to be filtered out by PSR's internal algorithms.
- linked_issues: tuple[str, ...]
- A tuple of issue numbers as strings, if the commit is contains issue
references.
If there are no issue references, this should be an empty tuple. Although, we generally refer to them as "issue numbers", it generally should be a string to adhere to the prefixes used by the VCS (ex. # for GitHub, GitLab, etc.) or issue tracker (ex. JIRA uses AAA-###).
- linked_merge_request: str
- A pull request or merge request definition, if the commit is labeled with
a pull/merge request number.
This is a string value which includes any special character prefix used by the VCS (e.g. # for GitHub, ! for GitLab).
- property linked_pull_request: str
- An alias to the linked_merge_request attribute.
- property message: str
- A string representation of the commit message.
This is a pass through property for convience to access the message attribute of the commit object.
If the message is of type bytes then it will be decoded to a UTF-8 string.
- release_notices: tuple[str, ...]
- A tuple of release notices, which are additional information about the
changes that affect the user.
An example would be a paragraph which begins with the text NOTICE: in the commit message but the parser generally strips the prefix and includes the rest of the paragraph in this list.
- scope: str
- The scope, as a string, parsed from the commit.
Generally an optional field based on the commit message style which means it very likely can be an empty string. Commit styles which do not have a meaningful concept of "scope" usually fill this field with an empty string.
- property short_hash: str
- A short representation of the hash value (in hex) of the commit.
- type: str
- The type of the commit as a string, per the commit message style.
This is up to the parser to implement; for example, the EmojiCommitParser parser fills this field with the emoji representing the most significant change for the commit.
- class semantic_release.commit_parser.token.ParsedMessageResult(bump: LevelBump, type: str, category: str, scope: str, descriptions: tuple[str, ...], breaking_descriptions: tuple[str, ...] = (), release_notices: tuple[str, ...] = (), linked_issues: tuple[str, ...] = (), linked_merge_request: str = '', include_in_changelog: bool = True)
- Bases: NamedTuple
A read-only named tuple object representing the result from parsing a commit message.
Essentially this is a data structure which holds the parsed information from a commit message without the actual commit object itself. Very helpful for unit testing.
Most of the fields will replicate the fields of a ParsedCommit
- breaking_descriptions: tuple[str, ...]
- Alias for field number 5
- bump: LevelBump
- Alias for field number 0
- category: str
- Alias for field number 2
- descriptions: tuple[str, ...]
- Alias for field number 4
- include_in_changelog: bool
- Alias for field number 9
- linked_issues: tuple[str, ...]
- Alias for field number 7
- linked_merge_request: str
- Alias for field number 8
- release_notices: tuple[str, ...]
- Alias for field number 6
- scope: str
- Alias for field number 3
- type: str
- Alias for field number 1
semantic_release.commit_parser.util module¶
- semantic_release.commit_parser.util.parse_paragraphs(text: str) -> list[str]
- This will take a text block and return a list containing each paragraph
with single line breaks collapsed into spaces.
To handle Windows line endings, carriage returns 'r' are removed before separating into paragraphs.
It will attempt to detect Git footers and they will not be condensed.
- Parameters
- text -- The text string to be divided.
- Returns
- A list of condensed paragraphs, as strings.
semantic_release.hvcs package¶
Submodules¶
semantic_release.hvcs.bitbucket module¶
Helper code for interacting with a Bitbucket remote VCS
- class semantic_release.hvcs.bitbucket.Bitbucket(remote_url: str, *, hvcs_domain: str | None = None, hvcs_api_domain: str | None = None, token: str | None = None, allow_insecure: bool = False, **kwargs: Any)
- Bases: RemoteHvcsBase
Bitbucket HVCS interface for interacting with BitBucket repositories
This class supports the following products:
- BitBucket Cloud
- BitBucket Data Center Server (on-premises installations)
This interface does its best to detect which product is configured based on the provided domain. If it is the official bitbucket.org, the default domain, then it is considered as BitBucket Cloud which uses the subdomain api.bitbucket.org/2.0 for api communication.
If the provided domain is anything else, than it is assumed to be communicating with an on-premise or 3rd-party maintained BitBucket instance which matches with the BitBucket Data Center Server product. The on-prem server product uses a path prefix for handling api requests which is configured to be server.domain/rest/api/1.0 based on the documentation in April 2024.
- compare_url(from_rev: str, to_rev: str) -> str
- Get the Bitbucket comparison link between two version tags. :param from_rev: The older version to compare. :param to_rev: The newer version to compare. :return: Link to view a comparison between the two versions.
- create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int | str
- Create or update a release for the given tag in a remote VCS, attaching the given changelog, if supported
- create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None = None, noop: bool = False) -> int | str
- Create a release in a remote VCS, if supported
Which includes uploading any assets as part of the release
- get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
- Return a list of functions that can be used as filters in a Jinja2
template
ex. filters to convert text to URLs for issues and commits
- remote_url(use_token: bool = True) -> str
- Get the remote url including the token for authentication if requested
- upload_dists(tag: str, dist_glob: str) -> int
- Upload built distributions to a release on a remote VCS that supports such uploads
semantic_release.hvcs.gitea module¶
Helper code for interacting with a Gitea remote VCS
- class semantic_release.hvcs.gitea.Gitea(remote_url: str, *, hvcs_domain: str | None = None, token: str | None = None, allow_insecure: bool = False, **_kwargs: Any)
- Bases: RemoteHvcsBase
Gitea helper class
- asset_upload_url(release_id: str) -> str
- Get the correct upload url for a release https://gitea.com/api/swagger#/repository/repoCreateReleaseAttachment :param release_id: ID of the release to upload to
- create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int
- Post release changelog :param version: The version number :param changelog: The release notes for this version
- Returns
- The status of the request
- create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None = None, noop: bool = False) -> int
- Create a new release
Ref: https://gitea.com/api/swagger#/repository/repoCreateRelease
- tag -- Tag to create release for
- release_notes -- The release notes for this version
- prerelease -- Whether or not this release should be specified as a prerelease
- Returns
- Whether the request succeeded
- edit_release_notes(release_id: int, release_notes: str) -> int
- Edit a release with updated change notes https://gitea.com/api/swagger#/repository/repoEditRelease :param id: ID of release to update :param release_notes: The release notes for this version
- Returns
- The ID of the release that was edited
- get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
- Return a list of functions that can be used as filters in a Jinja2
template
ex. filters to convert text to URLs for issues and commits
- get_release_id_by_tag(tag: str) -> int | None
- Get a release by its tag name https://gitea.com/api/swagger#/repository/repoGetReleaseByTag :param tag: Tag to get release for
- Returns
- ID of found release
- remote_url(use_token: bool = True) -> str
- Get the remote url including the token for authentication if requested
- upload_dists(tag: str, dist_glob: str) -> int
- Upload distributions to a release :param tag: Tag to upload for :param path: Path to the dist directory
- Returns
- The number of distributions successfully uploaded
- upload_release_asset(release_id: int, file: str, label: str | None = None) -> bool
- Upload an asset to an existing release https://gitea.com/api/swagger#/repository/repoCreateReleaseAttachment :param release_id: ID of the release to upload to :param file: Path of the file to upload :param label: this parameter has no effect
- Returns
- The status of the request
semantic_release.hvcs.github module¶
Helper code for interacting with a GitHub remote VCS
- class semantic_release.hvcs.github.Github(remote_url: str, *, hvcs_domain: str | None = None, hvcs_api_domain: str | None = None, token: str | None = None, allow_insecure: bool = False, **_kwargs: Any)
- Bases: RemoteHvcsBase
GitHub HVCS interface for interacting with GitHub repositories
This class supports the following products:
- GitHub Free, Pro, & Team
- GitHub Enterprise Cloud
- GitHub Enterprise Server (on-premises installations)
This interface does its best to detect which product is configured based on the provided domain. If it is the official github.com, the default domain, then it is considered as GitHub Enterprise Cloud which uses the subdomain api.github.com for api communication.
If the provided domain is anything else, than it is assumed to be communicating with an on-premise or 3rd-party maintained GitHub instance which matches with the GitHub Enterprise Server product. The on-prem server product uses a path prefix for handling api requests which is configured to be server.domain/api/v3 based on the documentation in April 2024.
- asset_upload_url(release_id: str) -> str | None
- Get the correct upload url for a release https://docs.github.com/en/enterprise-server@3.5/rest/releases/releases#get-a-release :param release_id: ID of the release to upload to :return: URL to upload for a release if found, else None
- compare_url(from_rev: str, to_rev: str) -> str
- Get the GitHub comparison link between two version tags. :param from_rev: The older version to compare. :param to_rev: The newer version to compare. :return: Link to view a comparison between the two versions.
- create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int
- Post release changelog :param tag: The version number :param release_notes: The release notes for this version :param prerelease: Whether or not this release should be created as a prerelease :return: The status of the request
- create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None = None, noop: bool = False) -> int
- Create a new release
REF: https://docs.github.com/rest/reference/repos#create-a-release
- tag -- Tag to create release for
- release_notes -- The release notes for this version
- prerelease -- Whether or not this release should be created as a prerelease
- assets -- a list of artifacts to upload to the release
- Returns
- the ID of the release
- edit_release_notes(release_id: int, release_notes: str) -> int
- Edit a release with updated change notes https://docs.github.com/rest/reference/repos#update-a-release :param release_id: ID of release to update :param release_notes: The release notes for this version :return: The ID of the release that was edited
- get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
- Return a list of functions that can be used as filters in a Jinja2
template
ex. filters to convert text to URLs for issues and commits
- get_release_id_by_tag(tag: str) -> int | None
- Get a release by its tag name https://docs.github.com/rest/reference/repos#get-a-release-by-tag-name :param tag: Tag to get release for :return: ID of release, if found, else None
- remote_url(use_token: bool = True) -> str
- Get the remote url including the token for authentication if requested
- upload_dists(tag: str, dist_glob: str) -> int
- Upload distributions to a release :param tag: Version to upload for :param dist_glob: Path to the dist directory :return: The number of distributions successfully uploaded
- upload_release_asset(release_id: int, file: str, label: str | None = None) -> bool
- Upload an asset to an existing release https://docs.github.com/rest/reference/repos#upload-a-release-asset :param release_id: ID of the release to upload to :param file: Path of the file to upload :param label: Optional custom label for this file :return: The status of the request
semantic_release.hvcs.gitlab module¶
Helper code for interacting with a Gitlab remote VCS
- class semantic_release.hvcs.gitlab.Gitlab(remote_url: str, *, hvcs_domain: str | None = None, token: str | None = None, allow_insecure: bool = False, **_kwargs: Any)
- Bases: RemoteHvcsBase
Gitlab HVCS interface for interacting with Gitlab repositories
- create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> str
- Create or update a release for the given tag in a remote VCS.
- tag -- The tag to create or update the release for
- release_notes -- The changelog description for this version only
- prerelease -- This parameter has no effect in GitLab
- ValueError -- If the release could not be created or updated
- gitlab.exceptions.GitlabAuthenticationError -- If the user is not authenticated
- GitlabUpdateError -- If the server cannot perform the request
- create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None = None, noop: bool = False) -> str
- Create a release in a remote VCS, adding any release notes and assets to it
- tag -- The tag to create the release for
- release_notes -- The changelog description for this version only
- prerelease -- This parameter has no effect in GitLab
- assets -- A list of paths to files to upload as assets (TODO: not implemented)
- noop -- If True, do not perform any actions, only logger intents
- edit_release_notes(release: ProjectRelease, release_notes: str) -> str
- Update the release notes for a given release.
- release -- The release object to update
- release_notes -- The new release notes
- get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
- Return a list of functions that can be used as filters in a Jinja2
template
ex. filters to convert text to URLs for issues and commits
- get_release_by_tag(tag: str) -> ProjectRelease | None
- Get a release by its tag name.
- Parameters
- tag -- The tag name to get the release for
- Returns
- gitlab.v4.objects.ProjectRelease or None if not found
- Raises
- gitlab.exceptions.GitlabAuthenticationError: If the user is not authenticated
- remote_url(use_token: bool = True) -> str
- Get the remote url including the token for authentication if requested
- upload_dists(tag: str, dist_glob: str) -> int
- Upload built distributions to a release on a remote VCS that supports such uploads
semantic_release.hvcs.remote_hvcs_base module¶
Common functionality and interface for interacting with Git remote VCS
- class semantic_release.hvcs.remote_hvcs_base.RemoteHvcsBase(remote_url: str, *_args: Any, **_kwargs: Any)
- Bases: HvcsBase
Interface for subclasses interacting with a remote VCS
This abstract class is defined to provide common helper functions and a set of basic methods that all remote VCS environments usually support.
If the remote vcs implementation (via subclass) does not support a functionality then it can just call super()'s method which defaults as a non-supported log message and empty results. This is more straightforward than checking for NotImplemented around every function call in the core library code.
- abstractmethod create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int | str
- Create or update a release for the given tag in a remote VCS, attaching the given changelog, if supported
- abstractmethod create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None = None, noop: bool = False) -> int | str
- Create a release in a remote VCS, if supported
Which includes uploading any assets as part of the release
- abstractmethod upload_dists(tag: str, dist_glob: str) -> int
- Upload built distributions to a release on a remote VCS that supports such uploads
semantic_release.hvcs.token_auth module¶
- class semantic_release.hvcs.token_auth.TokenAuth(token: str)
- Bases: AuthBase
requests Authentication for token based authorization. This allows us to attach the Authorization header with a token to a session.
semantic_release.hvcs.util module¶
- semantic_release.hvcs.util.build_requests_session(raise_for_status: bool = True, retry: bool | int | Retry = True, auth: TokenAuth | None = None) -> Session
- Create a requests session.
- raise_for_status -- If True, a hook to invoke raise_for_status be installed
- retry -- If true, it will use default Retry configuration. if an integer, it will use default Retry configuration with given integer as total retry count. if Retry instance, it will use this instance.
- auth -- Optional TokenAuth instance to be used to provide the Authorization header to the session
- Returns
- configured requests Session
- semantic_release.hvcs.util.suppress_http_error_for_codes(*codes: int) -> Callable[[Callable[[...], _R]], Callable[[...], _R | None]]
- For the codes given, return a decorator that will suppress HTTPErrors that are raised from responses that came with one of those status codes. The function will return False instead of raising the HTTPError
semantic_release.version package¶
Subpackages¶
semantic_release.version.declarations package¶
Submodules¶
semantic_release.version.declarations.enum module¶
- class semantic_release.version.declarations.enum.VersionStampType(*values)
- Bases: str, Enum
Enum for the type of version declaration
semantic_release.version.declarations.i_version_replacer module¶
- class semantic_release.version.declarations.i_version_replacer.IVersionReplacer
- Bases: object
Interface for subclasses that replace a version string in a source file.
Methods generally have a base implementation are implemented here but likely just provide a not-supported message but return gracefully
This class cannot be instantiated directly but must be inherited from and implement the designated abstract methods.
- abstractmethod parse() -> set[Version]
- Return a set of the versions which can be parsed from the file. Because a source can match in multiple places, this method returns a set of matches. Generally, there should only be one element in this set (i.e. even if the version is specified in multiple places, it should be the same version in each place), but enforcing that condition is not mandatory or expected.
- abstractmethod replace(new_version: Version) -> str
- Replace the version in the source content with new_version, and return the updated content.
- Parameters
- new_version -- The new version number as a Version instance
- abstractmethod update_file_w_version(new_version: Version, noop: bool = False) -> Path | None
- This method reads the underlying file, replaces each occurrence of the matched pattern, then writes the updated file.
- Parameters
- new_version -- The new version number as a Version instance
semantic_release.version.declarations.pattern module¶
- class semantic_release.version.declarations.pattern.PatternVersionDeclaration(path: Path | str, search_text: str, stamp_format: VersionStampType)
- Bases: IVersionReplacer
VersionDeclarationABC implementation representing a version number in a particular file. The version number is identified by a regular expression, which should be provided in search_text.
- property content: str
- A cached property that stores the content of the configured source file.
- classmethod from_string_definition(replacement_def: str, tag_format: str) -> PatternVersionDeclaration
- create an instance of self from a string representing one item of the "version_variables" list in the configuration
- parse() -> set[Version]
- Return the versions matching this pattern. Because a pattern can match in
multiple places, this method returns a set of matches. Generally, there
should only be one element in this set (i.e. even if the version is
specified in multiple places, it should be the same version in each
place), but it falls on the caller to check for this condition.
Deprecated since version 9.20.0: Function is unused and will be removed in a future release
- replace(new_version: Version) -> str
- Replace the version in the source content with new_version, and return the updated content.
- Parameters
- new_version -- The new version number as a Version instance
- update_file_w_version(new_version: Version, noop: bool = False) -> Path | None
- This method reads the underlying file, replaces each occurrence of the matched pattern, then writes the updated file.
- Parameters
- new_version -- The new version number as a Version instance
- class semantic_release.version.declarations.pattern.VersionSwapper(new_version_str: str, group_match_name: str)
- Bases: object
Callable to replace a version number in a string with a new version number.
semantic_release.version.declarations.toml module¶
- class semantic_release.version.declarations.toml.TomlVersionDeclaration(path: Path | str, search_text: str, stamp_format: VersionStampType)
- Bases: IVersionReplacer
- property content: str
- A cached property that stores the content of the configured source file.
- classmethod from_string_definition(replacement_def: str) -> TomlVersionDeclaration
- create an instance of self from a string representing one item of the "version_toml" list in the configuration
- parse() -> set[Version]
- Look for the version in the source content
Deprecated since version 9.20.0: Function is unused and will be removed in a future release
- replace(new_version: Version) -> str
- Replace the version in the source content with new_version, and return the updated content.
- update_file_w_version(new_version: Version, noop: bool = False) -> Path | None
- This method reads the underlying file, replaces each occurrence of the matched pattern, then writes the updated file.
- Parameters
- new_version -- The new version number as a Version instance
Submodules¶
semantic_release.version.algorithm module¶
- semantic_release.version.algorithm.next_version(repo: Repo, translator: VersionTranslator, commit_parser: CommitParser[ParseResult, ParserOptions], allow_zero_version: bool, major_on_zero: bool, prerelease: bool = False) -> Version
- Evaluate the history within repo, and based on the tags and commits in the repo history, identify the next semantic version that should be applied to a release
- Return a list of 2-tuples, where each element is a tuple (tag, version)
from the tags in the Git repo and their corresponding Version
according to Version.from_tag. The returned list is sorted
according to semver ordering rules.
Tags which are not matched by translator are ignored.
semantic_release.version.declaration module¶
- class semantic_release.version.declaration.VersionDeclarationABC(*args, **kwargs)
- Bases: ABC
ABC for classes representing a location in which a version is declared somewhere within the source tree of the repository
Deprecated since version 9.20.0: Refactored to composition paradigm using the new IVersionReplacer interface. This class will be removed in a future release
- property content: str
- The content of the source file in which the version is stored. This property is cached in the instance variable _content
- abstractmethod parse() -> set[Version]
- Return a set of the versions which can be parsed from the file. Because a source can match in multiple places, this method returns a set of matches. Generally, there should only be one element in this set (i.e. even if the version is specified in multiple places, it should be the same version in each place), but enforcing that condition is not mandatory or expected.
- abstractmethod replace(new_version: Version) -> str
- Update the versions. This method reads the underlying file, replaces each occurrence of the matched pattern, then writes the updated file. :param new_version: The new version number as a Version instance
- write(content: str) -> None
- Write new content back to the source path. Use alongside .replace():
>>> class MyVD(VersionDeclarationABC): ... def parse(self): ...
... def replace(self, new_version: Version): ... ... def write(self,
content: str): ...
>>> new_version = Version.parse("1.2.3") >>> vd = MyVD("path", r"__version__ = (?P<version>\d+\d+\d+)") >>> vd.write(vd.replace(new_version))
semantic_release.version.translator module¶
- class semantic_release.version.translator.VersionTranslator(tag_format: str = 'v{version}', prerelease_token: str = 'rc')
- Bases: object
Class to handle translation from Git tags into their corresponding Version instances.
- from_string(version_str: str) -> Version
- Return a Version instance from a string. Delegates directly to Version.parse, using the translator's own stored values for tag_format and prerelease
- from_tag(tag: str) -> Version | None
- Return a Version instance from a Git tag, if tag_format matches the format which would have generated the tag from a version. Otherwise return None. For example, a tag of 'v1.2.3' should be matched if tag_format = 'v{version}, but not if tag_format = staging--v{version}.
- str_to_tag(version_str: str) -> str
- Formats a version string into a tag name
semantic_release.version.version module¶
- bump(level: LevelBump) -> Version
- Return a new Version instance according to the level specified to bump. Note this will intentionally drop the build metadata - that should be added elsewhere for the specific build producing this version.
- classmethod parse(version_str: str, tag_format: str = 'v{version}', prerelease_token: str = 'rc') -> Version
- Parse version string to a Version instance. Inspired by semver.version:VersionInfo.parse, this implementation doesn't allow optional minor and patch versions.
- Parameters
- prerelease_token -- will be ignored if the version string is a prerelease, the parsed token from version_str will be used instead.
Submodules¶
semantic_release.const module¶
semantic_release.enums module¶
- class semantic_release.enums.LevelBump(*values)
- Bases: IntEnum
IntEnum representing valid types of bumps for a version. We use an IntEnum to enable ordering of levels.
- classmethod from_string(val: str) -> LevelBump
- Get the level from string representation. For backwards-compatibility, dashes are replaced with underscores so that: >>> LevelBump.from_string("no-release") == LevelBump.NO_RELEASE Equally, >>> LevelBump.from_string("minor") == LevelBump.MINOR
- class semantic_release.enums.SemanticReleaseLogLevels(*values)
- Bases: IntEnum
IntEnum representing the log levels used by semantic-release.
semantic_release.errors module¶
Custom Errors
- exception semantic_release.errors.AssetUploadError
- Bases: SemanticReleaseBaseError
Raised when there is a failure uploading an asset to a remote hvcs's release artifact storage.
- exception semantic_release.errors.BuildDistributionsError
- Bases: SemanticReleaseBaseError
Raised when there is a failure to build the distribution files.
- exception semantic_release.errors.CommitParseError
- Bases: SemanticReleaseBaseError
Raised when a commit cannot be parsed by a commit parser. Custom commit parsers should also raise this Exception
- exception semantic_release.errors.DetachedHeadGitError
- Bases: SemanticReleaseBaseError
Raised when the git repository is in a detached HEAD state
- exception semantic_release.errors.GitAddError
- Bases: SemanticReleaseBaseError
Raised when there is a failure to add files to the git index.
- exception semantic_release.errors.GitCommitEmptyIndexError
- Bases: SemanticReleaseBaseError
Raised when there is an attempt to commit an empty index.
- exception semantic_release.errors.GitCommitError
- Bases: SemanticReleaseBaseError
Raised when there is a failure to commit the changes.
- exception semantic_release.errors.GitPushError
- Bases: SemanticReleaseBaseError
Raised when there is a failure to push to the git remote.
- exception semantic_release.errors.GitTagError
- Bases: SemanticReleaseBaseError
Raised when there is a failure to tag the release.
- exception semantic_release.errors.IncompleteReleaseError
- Bases: SemanticReleaseBaseError
Raised when there is a failure amongst one of the api requests when creating a release on a remote hvcs.
- exception semantic_release.errors.InternalError
- Bases: SemanticReleaseBaseError
Raised when an internal error occurs, which should never happen
- exception semantic_release.errors.InvalidConfiguration
- Bases: SemanticReleaseBaseError
Raised when configuration is deemed invalid
- exception semantic_release.errors.InvalidParserOptions
- Bases: InvalidConfiguration
Raised when the parser options are invalid
- exception semantic_release.errors.InvalidVersion
- Bases: ValueError, SemanticReleaseBaseError
Raised when Version.parse attempts to parse a string containing an invalid version.
- exception semantic_release.errors.MissingGitRemote
- Bases: SemanticReleaseBaseError
Raised when repository is missing the configured remote origin or upstream
- exception semantic_release.errors.MissingMergeBaseError
- Bases: SemanticReleaseBaseError
Raised when the merge base cannot be found with the current history. Generally because of a shallow git clone.
- exception semantic_release.errors.NotAReleaseBranch
- Bases: InvalidConfiguration
Raised when semantic_release is invoked on a branch which isn't configured for releases
- exception semantic_release.errors.ParserLoadError
- Bases: SemanticReleaseBaseError
Raised when there is a failure to find, load, or instantiate a custom parser definition.
- exception semantic_release.errors.SemanticReleaseBaseError
- Bases: Exception
Base Exception from which all other custom Exceptions defined in semantic_release inherit
- exception semantic_release.errors.UnexpectedResponse
- Bases: SemanticReleaseBaseError
Raised when an HTTP response cannot be parsed properly or the expected structure is not found.
semantic_release.gitproject module¶
Module for git related operations.
semantic_release.globals module¶
Semantic Release Global Variables.
- semantic_release.globals.log_level: SemanticReleaseLogLevels = SemanticReleaseLogLevels.WARNING
- int: Logging level for semantic-release
- semantic_release.globals.logger: Logger = <Logger semantic_release (WARNING)>
- Logger for semantic-release
semantic_release.helpers module¶
- class semantic_release.helpers.ParsedGitUrl(scheme: str, netloc: str, namespace: str, repo_name: str)
- Bases: NamedTuple
Container for the elements parsed from a git URL
- namespace: str
- Alias for field number 2
- netloc: str
- Alias for field number 1
- repo_name: str
- Alias for field number 3
- scheme: str
- Alias for field number 0
- semantic_release.helpers.dynamic_import(import_path: str) -> Any
- Dynamically import an object from a conventionally formatted "module:attribute" string
- semantic_release.helpers.format_arg(value: Any) -> str
- Helper to format an argument an argument for logging
- semantic_release.helpers.logged_function(logger: Logger) -> Callable[[_FuncType[_R]], _FuncType[_R]]
- Decorator which adds debug logging of a function's input arguments and
return value.
The input arguments are logged before the function is called, and the return value is logged once it has completed.
- Parameters
- logger -- Logger to send output to.
- semantic_release.helpers.parse_git_url(url: str) -> ParsedGitUrl
- Attempt to parse a string as a git url http[s]://, git://, file://, or ssh format, into a ParsedGitUrl.
- supported examples:
- http://git.mycompany.com/username/myproject.git https://github.com/username/myproject.git https://gitlab.com/group/subgroup/myproject.git https://git.mycompany.com:4443/username/myproject.git git://host.xz/path/to/repo.git/ git://host.xz:9418/path/to/repo.git/ git@github.com:username/myproject.git <-- assumes ssh:// ssh://git@github.com:3759/myproject.git <-- non-standard, but assume user 3759 ssh://git@github.com:username/myproject.git ssh://git@bitbucket.org:7999/username/myproject.git git+ssh://git@github.com:username/myproject.git /Users/username/dev/remote/myproject.git <-- Posix File paths file:///Users/username/dev/remote/myproject.git C:/Users/username/dev/remote/myproject.git <-- Windows File paths file:///C:/Users/username/dev/remote/myproject.git
REFERENCE: https://stackoverflow.com/questions/31801271/what-are-the-supported-git-url-formats
Raises ValueError if the url can't be parsed.
- semantic_release.helpers.text_reducer(text: str, filter_pair: tuple[Pattern[str], str]) -> str
- Reduce function to apply mulitple filters to a string
- semantic_release.helpers.validate_types_in_sequence(sequence: Sequence, types: type | tuple[type, ...]) -> bool
- Validate that all elements in a sequence are of a specific type
Contributing¶
Love Python Semantic Release? Want to help out? There are many ways you can contribute to the project!
You can help by:
- Reporting bugs and issues
- Suggesting new features
- Improving the documentation
- Reviewing pull requests
- Contributing code
- Helping with translations
- Spreading the word about Python Semantic Release
- Participating in discussions
- Testing new features and providing feedback
No matter how you choose to contribute, please check out our Contributing Guidelines and know we appreciate your help!
Check out all the folks whom already contributed to Python Semantic Release and become one of them today!
Contributors
Contributing¶
If you want to contribute that is awesome. Remember to be nice to others in issues and reviews.
Please remember to write tests for the cool things you create or fix.
Unsure about something? No worries, open an issue.
Commit messages¶
Since python-semantic-release is released with python-semantic-release we need the commit messages to adhere to the Conventional Commits Specification. Although scopes are optional, scopes are expected where applicable. Changes should be committed separately with the commit type they represent, do not combine them all into one commit.
If you are unsure how to describe the change correctly just try and ask about it in your pr. If we think it should be something else or there is a pull-request without tags we will help out in adding or changing them.
Releases¶
This package is released by python-semantic-release on each master build, thus if there are changes that should result in a new release it will happen if the build is green.
Development¶
Install this module and the development dependencies
pip install -e .[dev,mypy,test]
And if you'd like to build the documentation locally
pip install -e .[docs] sphinx-autobuild --open-browser docs docs/_build/html
Testing¶
To test your modifications locally:
# Run type-checking, all tests across all supported Python versions tox # Run all tests for your current installed Python version (with full error output) pytest -vv --comprehensive # Run unit tests for your current installed Python version pytest # or pytest -vv -m unit # Run end-to-end tests for your current installed Python version (with full error output) pytest -vv -m e2e [--comprehensive]
The --comprehensive flag is optional and will run all the variations of tests and it does take significantly longer to run.
Building¶
This project is designed to be versioned and built by itself using the tool.semantic_release configuration in pyproject.toml. The setting tool.semantic_release.build_command defines the command to run to build the package.
The following is a copy of the build_command setting which can be run manually to build the package locally:
pip install -e .[build] python -m build .
----
GETTING STARTED¶
If you haven't done so already, install Python Semantic Release locally following the installation instructions.
If you are using a CI/CD service, you may not have to add Python Semantic Release to your project's dependencies permanently, but for the duration of this guide for the initial setup, you will need to have it installed locally.
Configuring PSR¶
Python Semantic Release ships with a reasonable default configuration but some aspects MUST be customized to your project. To view the default configuration, run the following command:
semantic-release generate-config
The output of the above command is the default configuration in TOML format without any modifications. If this is fine for your project, then you do not need to configure anything else.
PSR accepts overrides to the default configuration keys individually. If you don't define the key-value pair in your configuration file, the default value will be used.
By default, Python Semantic Release will look for configuration overrides in pyproject.toml under the TOML table [tool.semantic_release]. You may specify a different file using the -c/--config option, for example:
# In TOML format with top level table [semantic_release]
semantic-release -c releaserc.toml
# In JSON format with top level object key {"semantic_release": {}}
semantic-release -c releaserc.json
The easiest way to get started is to output the default configuration to a file, delete keys you do not need to override, and then edit the remaining keys to suit your project.
To set up in pyproject.toml, run the following command:
# In file redirect in bash semantic-release generate-config --pyproject >> pyproject.toml # Open your editor to edit the configuration vim pyproject.toml
SEE ALSO:
- cmd-generate-config
- Configuration
Configuring the Version Stamp Feature¶
One of the best features of Python Semantic Release is the ability to automatically stamp the new version number into your project files, so you don't have to manually update the version upon each release. The version that is stamped is automatically determined by Python Semantic Release from your commit messages which compliments automated versioning seamlessly.
The most crucial version stamp is the one in your project metadata, which is used by the Python Package Index (PyPI) and other package managers to identify the version of your package.
For Python projects, this is typically the version field in your pyproject.toml file. First, set up your project metadata with the base version value. If you are starting with a brand new project, set project.version = "0.0.0". If you are working on an existing project, set it to the last version number you released. Do not include any v prefix.
IMPORTANT:
Your project metadata might look like this in pyproject.toml:
[project] name = "my-package" version = "0.0.0" # Set this to the last released version or "0.0.0" for new projects description = "A sample Python package"
To configure PSR to automatically update this version number, you need to specify the file and value to update in your configuration. Since pyproject.toml uses TOML format, you will add the replacement specification to the tool.semantic_release.version_toml list. Update the following configuration in your pyproject.toml file to include the version variable location:
[tool.semantic_release] version_toml = ["pyproject.toml:project.version"] # Alternatively, if you are using poetry's 'version' key, then you would use: version_toml = ["pyproject.toml:tool.poetry.version"]
If you have other TOML files where you want to stamp the version, you can add them to the version_toml list as well. In the above example, there is an implicit assumption that you only want the version as the raw number format. If you want to specify the full tag value (e.g. v-prefixed version), then include :tf for "tag format" at the end of the version variable specification.
For non-TOML formatted files (such as JSON or YAML files), you can use the version_variables configuration key instead. This feature uses an advanced Regular Expression to find and replace the version variable in the specified files.
For Python files, its much more effective to use importlib instead which will allow you to dynamically import the version from your package metadata and not require your project to commit the version number bump to the repository. For example, in your package's base __init__.py
# my_package/__init__.py from importlib.metadata import version as get_version __version__ = get_version(__package__) # Note: __package__ must match your 'project.name' as defined in pyproject.toml
SEE ALSO:
- Configuration specification of version_toml
- Configuration specification of version_variables
Using PSR to Build your Project¶
PSR provides a convenient way to build your project artifacts as part of the versioning process now that you have stamped the version into your project files. To enable this, you will need to specify the build command in your configuration. This command will be executed after the next version has been determined, and stamped into your files but before a release tag has been created.
To set up the build command, add the following to your pyproject.toml file:
[tool.semantic_release] build_command = "python -m build --sdist --wheel ."
SEE ALSO:
- build_command - Configuration specification for the build command.
- build_command_env - Configuration specification for the build command environment variables.
Choosing a Commit Message Parser¶
PSR uses commit messages to determine the type of version bump that should be applied to your project. PSR supports multiple commit message parsing styles, allowing you to choose the one that best fits your project's needs. Choose one of the supported commit parsers defined in Commit Parsing, or provide your own and configure it in your pyproject.toml file.
Each commit parser has its own default configuration options so if you want to customize the parser behavior, you will need to specify the parser options you want to override.
[tool.semantic_release] commit_parser = "conventional" [tool.semantic_release.commit_parser_options] minor_tags = ["feat"] patch_tags = ["fix", "perf"] parse_squash_commits = true ignore_merge_commits = true
Choosing your Changelog¶
Prior to creating a release, PSR will generate a changelog from the commit messages of your project. The changelog is extremely customizable from the format to the content of each section. PSR ships with a default changelog template that will be used if you do not provide custom templates. The default should be sufficient for most projects and has its own set of configuration options.
For basic customization, you can choose either an traditional Markdown formatted changelog (default) or if you want to integrate with a Sphinx Documentation project, you can use the reStructuredText (RST) format. You can also choose the file name and location of where to write the default changelog.
To set your changelog location and changelog format, add the following to your pyproject.toml file:
[tool.semantic_release.changelog.default_templates] changelog_file = "docs/source/CHANGELOG.rst" output_format = "rst" # or "md" for Markdown format
Secondly, the more important aspect of configuring your changelog is to define Commit Exclusion Patterns or patterns that will be used to filter out commits from the changelog. PSR does NOT (yet) come with a built-in set of exclusion patterns, so you will need to define them yourself. These commit patterns should be in line with your project's commit parser configuration.
To set commit exclusion patterns for a conventional commits parsers, add the following to your pyproject.toml file:
[tool.semantic_release.changelog] # Recommended patterns for conventional commits parser that is scope aware exclude_commit_patterns = [
'''chore(?:\([^)]*?\))?: .+''',
'''ci(?:\([^)]*?\))?: .+''',
'''refactor(?:\([^)]*?\))?: .+''',
'''style(?:\([^)]*?\))?: .+''',
'''test(?:\([^)]*?\))?: .+''',
'''build\((?!deps\): .+)''',
'''Initial [Cc]ommit.*''', ]
SEE ALSO:
- Changelog - Customize your changelog
- changelog.mode - Choose the changelog mode ('update' or 'init')
- Migrating an Existing Changelog
Defining your Release Branches¶
PSR provides a powerful feature to manage release types across multiple branches which can allow you to configure your project to have different release branches for different purposes, such as pre-release branches, beta branches, and your stable releases.
NOTE:
To define an alpha pre-release branch when you are working on a fix or new feature, you can add the following to your pyproject.toml file:
[tool.semantic_release.branches.alpha] # Matches branches with the prefixes 'feat/', 'fix/', or 'perf/'. match = "^(feat|fix|perf)/.+" prerelease = true prerelease_token = "alpha"
Any time you execute semantic-release version on a branch with the prefix feat/, fix/, or perf/, PSR will determine if a version bump is needed and if so, the resulting version will be a pre-release version with the alpha token. For example,
| Branch | Version Bump | Current Version | Next Version |
| main | Patch | 1.0.0 | 1.0.1 |
| fix/bug-1 | Patch | 1.0.0 | 1.0.1-alpha.1 |
SEE ALSO:
- •
- Multibranch Releases - Learn about multi-branch releases and how to configure them.
Configuring VCS Releases¶
You can set up Python Semantic Release to create Releases in your remote version control system, so you can publish assets and release notes for your project.
In order to do so, you will need to place an authentication token in the appropriate environment variable so that Python Semantic Release can authenticate with the remote VCS to push tags, create releases, or upload files.
GitHub (GH_TOKEN)¶
For local publishing to GitHub, you should use a personal access token and store it in your environment variables. Specify the name of the environment variable in your configuration setting remote.token. The default is GH_TOKEN.
To generate a token go to https://github.com/settings/tokens and click on "Generate new token".
For Personal Access Token (classic), you will need the repo scope to write (ie. push) to the repository.
For fine-grained Personal Access Tokens, you will need the contents permission.
GitLab (GITLAB_TOKEN)¶
A personal access token from GitLab. This is used for authenticating when pushing tags, publishing releases etc. This token should be stored in the GITLAB_TOKEN environment variable.
Gitea (GITEA_TOKEN)¶
A personal access token from Gitea. This token should be stored in the GITEA_TOKEN environment variable.
Bitbucket (BITBUCKET_TOKEN)¶
Bitbucket does not support uploading releases but can still benefit from automated tags and changelogs. The user has three options to push changes to the repository:
- 1.
- Use SSH keys.
- 2.
- Use an App Secret, store the secret in the BITBUCKET_TOKEN environment variable and the username in BITBUCKET_USER.
- 3.
- Use an Access Token for the repository and store it in the BITBUCKET_TOKEN environment variable.
SEE ALSO:
- Changelog - customize your project's changelog.
- Custom Release Notes - customize the published release notes
- version --vcs-release/--no-vcs-release - enable/disable VCS release creation.
Testing your Configuration¶
It's time to test your configuration!
# 1. Run the command in no-operation mode to see what would happen semantic-release -v --noop version # 2. If the output looks reasonable, try to run the command without any history changes # '-vv' will give you verbose debug output, which is useful for troubleshooting # commit parsing issues. semantic-release -vv version --no-commit --no-tag # 3. Evaluate your repository to see the changes that were made but not committed # - Check the version number in your pyproject.toml # - Check the distribution files from the build command # - Check the changelog file for the new release notes # 4. If everything looks good, make sure to commit/save your configuration changes git add pyproject.toml git commit -m "chore(config): configure Python Semantic Release" # 5. Now, try to run the release command with your history changes but without pushing semantic-release -v version --no-push --no-vcs-release # 6. Check the result on your local repository git status git log --graph --decorate --all # 7a. If you are happy with the release history and resulting commit & tag, # reverse your changes before trying the full release command. git tag -d v0.0.1 # replace with the actual version you released git reset --hard HEAD~1 # 7b. [Optional] Once you have configured a remote VCS token, try # running the full release command to update the remote repository. semantic-release version --push --vcs-release # This is optional as you may not want a personal access token set up or make # make the release permanent yet.
SEE ALSO:
- cmd-version
- Increasing Verbosity
Configuring CI/CD¶
PSR is meant to help you release at speed! See our CI/CD Configuration guides under the Automated Releases section.
AUTHOR¶
Python Semantic Release Team
COPYRIGHT¶
2025, Python Semantic Release Team
| October 1, 2025 | 10.4.1 |