feat(build-wheelhouse): add opt-in inputs to fetch full git history & tags for versioning

[viseshrp]

Similar to #1024

Why

I am modifying pydynamicreporting to obtain its package version from Git metadata using hatch-vcs. The existing build action performs a shallow checkout (fetch-depth: 1) and does not fetch tags, which prevents Hatch’s VCS plugin from detecting version tags during python -m build. As a result, the build falls back to a default 0.1 version instead of the actual version to be obtained from git tags.

What changed

• Added two optional, pass-through inputs to the composite action’s checkout step:
  • checkout-fetch-depth (default: '1')
  • checkout-fetch-tags (default: 'false')
• These map directly to actions/checkout inputs, allowing repositories to opt in to fetching full Git history and tags when required.
• Default behavior remains unchanged to avoid side effects for existing consumers.

Backwards compatibility

• No breaking changes — all existing workflows should continue to perform shallow checkouts.
• Projects that require full tag history for VCS-based versioning can explicitly opt in.

How to opt in (example)

- uses: ansys/actions/build-wheelhouse@v10
  with:
    checkout-fetch-depth: '0'    # fetch full history
    checkout-fetch-tags:  'true' # fetch tags for hatch-vcs

Note: Hatch’s vcs or vcs-dev version sources rely on both commit history and annotated tags.
Use fetch-depth: 0 together with fetch-tags: true to ensure accurate version resolution.

When this is needed

• Projects using:
  • hatch-vcs
  • Hatch vcs or vcs-dev version sources
  • setuptools_scm or other Git tag–based versioning tools
• Any build logic that uses git describe, git tag, or commit metadata during build time.

[SMoraisAnsys]

Aligns with what was already performed in #1024.

I missed that in the previous PR but couldn't you handled this logic by setting inputs.checkout to false and handling the checkout on your side ?

I'm asking that because this change could be performed on basically every action afterward or we should revert #1024 and let users handle the checkout logic however they want.

[RobPasMue]

I'm asking that because this change could be performed on basically every action afterward or we should revert #1024 and let users handle the checkout logic however they want.

I agree - after thinking it through a bit more it might be best to check out the repo yourself with the desired conditions and then enabling the checkout: false option on your side. This would streamline things on our side - and we would have to revert #1024 as well.

[viseshrp]

Yes, that works for me. Thank you for pointing it out. - Visesh

…

On Tue, Apr 21, 2026, 3:35 AM Roberto Pastor Muela ***@***.***> wrote: *RobPasMue* left a comment (ansys/actions#1269) <#1269?email_source=notifications&email_token=ACY2MC2CDOS3J3W2EJRJHDD4W4QELA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRYGY3TCNRZGE22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4286716915> I'm asking that because this change could be performed on basically every action afterward or we should revert #1024 <#1024> and let users handle the checkout logic however they want. I agree - after thinking it through a bit more it might be best to check out the repo yourself with the desired conditions and then enabling the checkout: false option on your side. This would streamline things on our side - and we would have to revert #1024 <#1024> as well. — Reply to this email directly, view it on GitHub <#1269?email_source=notifications&email_token=ACY2MC2CDOS3J3W2EJRJHDD4W4QELA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRYGY3TCNRZGE22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4286716915>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACY2MC3JOH4BPM4QSTMI6UD4W4QELAVCNFSM6AAAAACX74EIUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEOBWG4YTMOJRGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>