python-semantic-release 9.20.0__tar.gz → 9.21.0__tar.gz

{python_semantic_release-9.20.0/src/python_semantic_release.egg-info → python_semantic_release-9.21.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.20.0
+Version: 9.21.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT

{python_semantic_release-9.20.0 → python_semantic_release-9.21.0}/docs/automatic-releases/github-actions.rst

@@ -337,7 +337,7 @@ before the :ref:`version <cmd-version>` subcommand.
 
   .. code:: yaml
 
-    - uses: python-semantic-release/python-semantic-release@v9.19.1
+    - uses: python-semantic-release/python-semantic-release@v9.20.0
       with:
         root_options: "-vv --noop"
 
@@ -576,7 +576,7 @@ before the :ref:`publish <cmd-publish>` subcommand.
 
   .. code:: yaml
 
-    - uses: python-semantic-release/publish-action@v9.19.1
+    - uses: python-semantic-release/publish-action@v9.20.0
       with:
         root_options: "-vv --noop"
 
@@ -643,7 +643,7 @@ Examples
 Common Workflow Example
 -----------------------
 
-The following is a common workflow example that uses both the Python Semantic Release Action
+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
@@ -661,30 +661,74 @@ to the GitHub Release Assets as well.
     jobs:
       release:
         runs-on: ubuntu-latest
-        concurrency: release
+        concurrency:
+          group: ${{ github.workflow }}-release-${{ github.ref_name }}
+          cancel-in-progress: false
 
         permissions:
           id-token: write
           contents: write
 
         steps:
-          # Note: we need to checkout the repository at the workflow sha in case during the workflow
-          # the branch was updated. To keep PSR working with the configured release branches,
-          # we force a checkout of the desired release branch but at the workflow sha HEAD.
-          - name: Setup | Checkout Repository at workflow sha
+          # 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
-              ref: ${{ github.sha }}
 
-          - name: Setup | Force correct release branch on workflow sha
+          - name: Setup | Force release branch to be at workflow sha
             run: |
-              git checkout -B ${{ github.ref_name }} ${{ github.sha }}
+              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 | cut -d' ' -f2 | grep -E '\.{3}' | cut -d'.' -f4)"
+              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@v9.19.1
+            uses: python-semantic-release/python-semantic-release@v9.20.0
             with:
               github_token: ${{ secrets.GITHUB_TOKEN }}
               git_committer_name: "github-actions"
@@ -695,7 +739,7 @@ to the GitHub Release Assets as well.
             if: steps.release.outputs.released == 'true'
 
           - name: Publish | Upload to GitHub Release Assets
-            uses: python-semantic-release/publish-action@v9.19.1
+            uses: python-semantic-release/publish-action@v9.20.0
             if: steps.release.outputs.released == 'true'
             with:
               github_token: ${{ secrets.GITHUB_TOKEN }}
@@ -706,6 +750,11 @@ to the GitHub Release Assets as well.
   one release job in the case if there are multiple pushes to ``main`` in a short period
   of time.
 
+  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::
   You must set ``fetch-depth`` to 0 when using ``actions/checkout@v4``, since
   Python Semantic Release needs access to the full history to build a changelog
@@ -721,6 +770,7 @@ to the GitHub Release Assets as well.
   case, you will also need to pass the new token to ``actions/checkout`` (as
   the ``token`` input) in order to gain push access.
 
+.. _#1201: https://github.com/python-semantic-release/python-semantic-release/issues/1201
 .. _concurrency: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idconcurrency
 
 Version Overrides Example
@@ -744,7 +794,7 @@ The equivalent GitHub Action configuration would be:
 
   - name: Action | Semantic Version Release
     # Adjust tag with desired version if applicable.
-    uses: python-semantic-release/python-semantic-release@v9.19.1
+    uses: python-semantic-release/python-semantic-release@v9.20.0
     with:
       github_token: ${{ secrets.GITHUB_TOKEN }}
       force: patch
@@ -772,13 +822,13 @@ Publish Action.
 .. code:: yaml
 
    - name: Release Project 1
-     uses: python-semantic-release/python-semantic-release@v9.19.1
+     uses: python-semantic-release/python-semantic-release@v9.20.0
      with:
        directory: ./project1
        github_token: ${{ secrets.GITHUB_TOKEN }}
 
    - name: Release Project 2
-     uses: python-semantic-release/python-semantic-release@v9.19.1
+     uses: python-semantic-release/python-semantic-release@v9.20.0
      with:
        directory: ./project2
        github_token: ${{ secrets.GITHUB_TOKEN }}

{python_semantic_release-9.20.0 → python_semantic_release-9.21.0}/docs/configuration.rst

@@ -1209,9 +1209,9 @@ 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 ${NEW_RELEASE_TAG}, the ``version_toml`` option accepts a colon-separated definition
+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 ${NEW_RELEASE_TAG}, it also accepts an optional
+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**
@@ -1271,9 +1271,9 @@ 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 ${NEW_RELEASE_TAG}, the ``version_variables`` option accepts a
+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 ${NEW_RELEASE_TAG}, it also accepts
+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**
@@ -1283,7 +1283,7 @@ an optional 3rd part to allow configuration of the format type.
 
 If the format type is not specified, it will default to the number format.
 
-Prior to ${NEW_RELEASE_TAG}, PSR only supports entries with the first 2-parts
+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.
 

{python_semantic_release-9.20.0 → python_semantic_release-9.21.0}/pyproject.toml

@@ -6,7 +6,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-semantic-release"
-version = "9.20.0"
+version = "9.21.0"
 description = "Automatic Semantic Versioning for Python projects"
 requires-python = ">=3.8"
 license = { text = "MIT" }
@@ -39,6 +39,7 @@ dependencies = [
 ]
 
 [project.scripts]
+python-semantic-release = "semantic_release.__main__:main"
 semantic-release = "semantic_release.__main__:main"
 psr = "semantic_release.__main__:main"
 

{python_semantic_release-9.20.0 → python_semantic_release-9.21.0/src/python_semantic_release.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.20.0
+Version: 9.21.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT

{python_semantic_release-9.20.0 → python_semantic_release-9.21.0}/src/python_semantic_release.egg-info/entry_points.txt

@@ -1,3 +1,4 @@
 [console_scripts]
 psr = semantic_release.__main__:main
+python-semantic-release = semantic_release.__main__:main
 semantic-release = semantic_release.__main__:main

{python_semantic_release-9.20.0 → python_semantic_release-9.21.0}/src/semantic_release/__init__.py

@@ -24,7 +24,7 @@ from semantic_release.version import (
     tags_and_versions,
 )
 
-__version__ = "9.20.0"
+__version__ = "9.21.0"
 
 __all__ = [
     "CommitParser",

{python_semantic_release-9.20.0 → python_semantic_release-9.21.0}/tests/e2e/test_main.py

@@ -1,6 +1,7 @@
 from __future__ import annotations
 
 import json
+import subprocess
 from pathlib import Path
 from textwrap import dedent
 from typing import TYPE_CHECKING
@@ -12,7 +13,7 @@ from pytest_lazy_fixtures.lazy_fixture import lf as lazy_fixture
 from semantic_release import __version__
 from semantic_release.cli.commands.main import main
 
-from tests.const import MAIN_PROG_NAME, VERSION_SUBCMD
+from tests.const import MAIN_PROG_NAME, SUCCESS_EXIT_CODE, VERSION_SUBCMD
 from tests.fixtures.repos import repo_w_no_tags_conventional_commits
 from tests.util import assert_exit_code, assert_successful_exit_code
 
@@ -25,6 +26,30 @@ if TYPE_CHECKING:
     from tests.fixtures.git_repo import BuiltRepoResult
 
 
+@pytest.mark.parametrize(
+    "project_script_name",
+    [
+        "python-semantic-release",
+        "semantic-release",
+        "psr",
+    ],
+)
+def test_entrypoint_scripts(project_script_name: str):
+    # Setup
+    command = str.join(" ", [project_script_name, "--version"])
+    expected_output = f"semantic-release, version {__version__}\n"
+
+    # Act
+    proc = subprocess.run(  # noqa: S602, PLW1510
+        command, shell=True, text=True, capture_output=True
+    )
+
+    # Evaluate
+    assert SUCCESS_EXIT_CODE == proc.returncode  # noqa: SIM300
+    assert expected_output == proc.stdout
+    assert not proc.stderr
+
+
 def test_main_prints_version_and_exits(cli_runner: CliRunner):
     cli_cmd = [MAIN_PROG_NAME, "--version"]