feat(ansible): read .python-version in release workflow

.github/workflows/release-ansible-collection.yml

@@ -14,10 +14,12 @@ on:
         required: true
         type: string
       python_version:
-        description: 'Python version to use'
+        description: >-
+          Python version to use. When empty, the workflow reads the repo-root
+          .python-version file, falling back to 3.11 if that is absent too.
         required: false
         type: string
-        default: '3.11'
+        default: ''
     secrets:
       galaxy_api_key:
         description: 'Ansible Galaxy API key'
@@ -58,10 +60,28 @@ jobs:
             echo "found=false" >> $GITHUB_OUTPUT
           fi
 
+      - name: Resolve Python version
+        id: python
+        env:
+          PYTHON_VERSION_INPUT: ${{ inputs.python_version }}
+        run: |
+          FILE_VERSION=""
+          if [ -f ".python-version" ]; then
+            FILE_VERSION="$(head -n1 .python-version | tr -d '[:space:]')"
+          fi
+          if [ -n "$PYTHON_VERSION_INPUT" ]; then
+            VERSION="$PYTHON_VERSION_INPUT"
+          elif [ -n "$FILE_VERSION" ]; then
+            VERSION="$FILE_VERSION"
+          else
+            VERSION="3.11"
+          fi
+          echo "version=$VERSION" >> "$GITHUB_OUTPUT"
+
       - name: Set up Python
         uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6
         with:
-          python-version: ${{ inputs.python_version }}
+          python-version: ${{ steps.python.outputs.version }}
 
       - name: Build and Publish Collection
         uses: artis3n/ansible_galaxy_collection@ffbca2460a5a1c600b941bbf1536bd61de1c2227 # v3

AGENTS.md

@@ -278,12 +278,11 @@ file on a current released Python (custom manager, `python-version` datasource).
 A collection without `.python-version` is drift — add one. `requires_ansible` is
 `>=2.18.0` across the collections.
 
-**Release-path caveat**: `release-ansible-collection.yml` has its own
-`python_version` input (default `3.11`) and does **not** read `.python-version`.
-A collection that bumps `.python-version` must also pass the matching
-`python_version` to the reusable workflow, or the publish build keeps using the
-old default. (Follow-up: make the release workflow read `.python-version` when
-present so the file is truly authoritative.)
+`release-ansible-collection.yml` resolves the Python version in this order:
+the `python_version` input when set, otherwise the repo-root `.python-version`
+file, otherwise `3.11`. So `.python-version` is authoritative for the publish
+build with no extra wiring — only pass `python_version` to override it for a
+specific release.
 
 ---
 

CHANGELOG.md

@@ -27,6 +27,12 @@ This is a rolling release - changes are deployed continuously to `main`.
   `release.yml` to `tag.yml` (the event-focused template slot for tag pushes,
   alongside `pull-request.yml` / `nightly-security.yml`); the `name:` stays
   `Release - Ansible Collection`
+- **release-ansible-collection.yml**: Read the publish Python version from the
+  repo-root `.python-version` file when the `python_version` input is not set
+  (input → `.python-version` → `3.11` fallback). The input default changed from
+  `3.11` to empty; callers that pass `python_version` are unaffected, callers
+  that relied on the silent `3.11` default now get `.python-version` if present.
+  Makes `.python-version` authoritative for releases.
 
 ---