Validate publish tags before checkout/build/publish

[Copilot]

The Publish to PyPI workflow accepted the release tag inline at checkout time, which left tag format unchecked and duplicated tag resolution logic. This change resolves the tag once, validates it against the required XX.XX.XX format, and reuses that value for checkout.

• Tag resolution

  • Adds an early Determine release tag step in release-build
  • Writes the selected tag (workflow_dispatch input or release tag) to $GITHUB_OUTPUT

• Tag validation

  • Adds a bash validation step immediately after tag resolution
  • Fails fast unless the tag matches ^[0-9]{2}\.[0-9]{2}\.[0-9]{2}$
  • Keeps invalid tags from reaching checkout, build, or publish

• Checkout update

  • Replaces the inline checkout ref expression with the validated step output
  • Leaves the rest of the workflow behavior unchanged

- name: Determine release tag
  id: release_tag
  shell: bash
  run: echo "tag=${{ inputs.tag || github.event.release.tag_name }}" >> "$GITHUB_OUTPUT"

- name: Validate tag format
  shell: bash
  run: |
    if [[ ! "${{ steps.release_tag.outputs.tag }}" =~ ^[0-9]{2}\.[0-9]{2}\.[0-9]{2}$ ]]; then
      echo "Invalid release tag '${{ steps.release_tag.outputs.tag }}'. Expected format: XX.XX.XX"
      exit 1
    fi

- uses: actions/checkout@v4
  with:
    ref: refs/tags/${{ steps.release_tag.outputs.tag }}

Original prompt

Please create a pull request in repository barentine/double_helix making the minimal change to .github/workflows/publish.yml so the workflow validates release tags in the exact format XX.XX.XX before checkout/build/publish.

Context:

• The repo has a Publish to PyPI workflow at .github/workflows/publish.yml.
• The workflow currently supports both release and workflow_dispatch triggers.
• It currently checks out refs/tags/${{ inputs.tag || github.event.release.tag_name }} directly.
• The goal is to add the smallest safe change so that the workflow determines the tag once, validates it against the regex ^[0-9]{2}\.[0-9]{2}\.[0-9]{2}$, and then uses that validated tag for checkout.
• Keep the existing behavior otherwise unchanged.
• Do not make unrelated edits.

Suggested implementation:

• In job release-build, add a step to determine the tag and write it to $GITHUB_OUTPUT.
• Add a step immediately after to validate the tag format in bash, failing with a clear message if invalid.
• Update the checkout step to use the validated step output instead of the inline expression.
• Keep the change minimal and preserve current comments/formatting as much as practical.

Please open a pull request with a concise title and summary of the minimal change.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User:
pypi-publish
Tag "26.05.21" is not allowed to deploy to pypi due to environment protection rules.

Assistant: The failure is because GitHub environment protection blocked the deploy.

Your pypi-publish job is attached to the pypi environment in .github/workflows/publish.yml:

environment:
  name: pypi
  url: https://pypi.org/project/pyme-double-helix/${{ inputs.tag || github.event.release.tag_name }}

And GitHub told you exactly why it stopped:

Tag "26.05.21" is not allowed to deploy to pypi due to environment protection rules.

So the difference between the successful April 1, 2026 run and the failed May 21, 2026 run is probably not the package build or PyPI upload credentials. The workflow reached the deployment gate, but the tag name 26.05.21 did not match the deployment policy configured for the pypi environment.

Most likely cause:

• Your pypi environment has a deployment branch/tag rule restricting which tags may deploy.
• Earlier successful tags likely matched that rule.
• 26.05.21 did not.

What to check in GitHub:

1. Go to Settings → Environments → pypi
2. Look at:
   • Deployment branches and tags
   • any selected tag patterns
3. Compare the allowed pattern with your release tag:
   • failed tag: 26.05.21

Common examples of mismatches:

• environment allows v*, but your tag is 26.05.21
• environment allows release/*
• environment allows only protected branches, not tags
• environment was changed after April 1

So if your intended release format is 26.05.21, the fix is one of:

• Update the environment rule to allow tags like 26.05.21, or
• Rename future tags to match the existing rule, e.g. v26.05.21 if the rule expects v*

If you want, I can help you with either of these next:

1. infer the likely tag pattern from your workflow/history,
2. suggest the exact environment rule to use,
3. or patch publish.yml so your manual workflow_dispatch input description and release process are consistent.

User: please start by 1. infer the likely tag

Assistant: The likely allowed tag pattern is v*, and your failed tag 26.05.21 probably missed the required leading v.

Why I think that:

1. In your workflow’s manual trigger input, you documented the expected tag format as:

workflow_dispatch:
  inputs:
    tag:
      description: 'Git tag to build and publish (e.g. v26.03.03)'
      required: true
      type: string

That example strongly suggests your intended convention is tags like v26.03.03, not 26.05.21.

2. The failed run explicitly says:

• Tag: 26.05.21
• blocked by environment protection rules

That is exactly the kind of failure you’d expect if the environment allows something like:

• v*
  or a narrower pattern such as:
• v*.*.*

3. Your successful April 1, 2026 publish run happened after the PyPI automation workflow was added, so it’s plausible that release used the expected prefixed format while this latest one did not.

So my best inference is:

• expected tag style: v26.05.21
• actual failed tag: 26.05.21
• likely environment rule: v* or v*.*.*

What I’d do next:

• Check Settings → Environments → pypi → Deployment branches and tags
• If it currently allows `...

This pull request was created from Copilot chat.