From 7826af98656091797291f195d65598177a5ebb3c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Simon=20B=C3=A4rlocher?= Date: Wed, 17 Jun 2026 22:59:48 +0200 Subject: [PATCH 1/2] feat(ansible): read .python-version in release workflow MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit release-ansible-collection.yml had a python_version input defaulting to 3.11 and never read the repo-root .python-version file, so a collection that bumped .python-version still published with 3.11 unless it also passed the input. Add a "Resolve Python version" step that picks the input when set, otherwise the first line of .python-version, otherwise 3.11. The input default changes from 3.11 to empty; callers passing python_version are unaffected, callers that relied on the silent 3.11 default now get .python-version when present. This makes .python-version authoritative for the publish build, closing the caveat documented in AGENTS.md. The input is passed via env into the resolve step rather than interpolated into the script. Signed-off-by: Simon Bärlocher --- .../workflows/release-ansible-collection.yml | 22 ++++++++++++++++--- AGENTS.md | 11 +++++----- CHANGELOG.md | 6 +++++ 3 files changed, 30 insertions(+), 9 deletions(-) diff --git a/.github/workflows/release-ansible-collection.yml b/.github/workflows/release-ansible-collection.yml index 16cc791..de4f3ec 100644 --- a/.github/workflows/release-ansible-collection.yml +++ b/.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,24 @@ jobs: echo "found=false" >> $GITHUB_OUTPUT fi + - name: Resolve Python version + id: python + env: + PYTHON_VERSION_INPUT: ${{ inputs.python_version }} + run: | + if [ -n "$PYTHON_VERSION_INPUT" ]; then + VERSION="$PYTHON_VERSION_INPUT" + elif [ -f ".python-version" ]; then + VERSION="$(head -n1 .python-version | tr -d '[:space:]')" + 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 diff --git a/AGENTS.md b/AGENTS.md index 8523bf4..fd04d2e 100644 --- a/AGENTS.md +++ b/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. --- diff --git a/CHANGELOG.md b/CHANGELOG.md index c596362..be147f8 100644 --- a/CHANGELOG.md +++ b/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. --- From f31bd0fd78a21e7b954744ff81a654875579aad0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Simon=20B=C3=A4rlocher?= Date: Wed, 17 Jun 2026 23:02:37 +0200 Subject: [PATCH 2/2] fix(ansible): fall back to 3.11 on empty .python-version MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit An existing but empty or whitespace-only .python-version yielded an empty VERSION, passed as an empty python-version to setup-python instead of the documented 3.11 fallback. Read the file into FILE_VERSION first and treat an empty result the same as an absent file. Signed-off-by: Simon Bärlocher --- .github/workflows/release-ansible-collection.yml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/.github/workflows/release-ansible-collection.yml b/.github/workflows/release-ansible-collection.yml index de4f3ec..c2ed5d6 100644 --- a/.github/workflows/release-ansible-collection.yml +++ b/.github/workflows/release-ansible-collection.yml @@ -65,10 +65,14 @@ jobs: 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 [ -f ".python-version" ]; then - VERSION="$(head -n1 .python-version | tr -d '[:space:]')" + elif [ -n "$FILE_VERSION" ]; then + VERSION="$FILE_VERSION" else VERSION="3.11" fi