Failure with --require-hashes because importlib_resources~=5.7, when should be ==5.7?

[ModeSevenIndustrialSolutions]

Description

Intermittent build failures in workflows calling sigstore/gh-action-sigstore-python, depending on the Python build version being used. This can occasionally block our releases, depending on the repository content and wider CI context.

Version: sigstore/[email protected] [latest release]

It looks like the action is trying to install dependencies with --require-hashes mode, but one of the dependencies (importlib_resources~=5.7) doesn't have a pinned version with ==.

I'm calling with: sigstore/gh-action-sigstore-python@f832326173235dcb00dd5d92cd3f353de3188e6c

Here's the error:

ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    importlib_resources~=5.7 from https://files.pythonhosted.org/packages/7a/68/bd9dd6bbf06772c7accce77d0354d783333fbe712a60b08fc13540c05422/importlib_resources-5.13.0-py3-none-any.whl (from sigstore==4.1.0->-r /home/runner/work/_actions/sigstore/gh-action-sigstore-python/f832326173235dcb00dd5d92cd3f353de3188e6c/requirements/main.txt (line 481))

[ModeSevenIndustrialSolutions]

[ModeSevenIndustrialSolutions]

Proposed fix in: https://github.com/sigstore/gh-action-sigstore-python/pull/255

[jku]

So based on the screenshot:

• other builds work but python 3.10 fails: dependency resolution can depend on python version so that would make some sense...
• except we now use Python version pinning: Internally the action should always use Python 3.14 regardless of what you have installed on the host (this comes as a side effect of using uv venv as it respects .python-version)

I can only theorize that the python version pinning is somehow not working in this case. Can you provide complete logs?

EDIT: I think I see the issues -- see later post. Making the logs available won't hurt but maybe are not necessary.

[jku]

Can you provide complete logs?

specifically I'd like to see the complete log of the the workflow step that runs sigstore/gh-action-sigstore-python -- at least from a failing run.

Maybe seeing the workflow file would help as well -- I've tested the action on python 3.10 and it works as expected for me so there is some moving part here that I don't see yet.

[jku]

Actually, there are two problems:

1. the python version management has not been released yet -- I believe just a new release will likely fix your current issue

2. However, the python version selection still has a bug

• setup/create-venv.sh calls uv venv with the expectation that it respects .python-version
• this works great in our selftest: a .python-version is found and used...
• but in actual workflows, the .python-version is in the action path, not working directory. So you don't actually get Python 3.14

[jku]

I would suggest:

• let's fix #258
• make a new release asap

My apologies for not releasing the python version management stuff earlier: I really thought that was in 3.1 already but somehow got confused -- I believe you would not have seen the bug if that had been done

[jku]

@ModeSevenIndustrialSolutions if you are able to test your workflow with sigstore/gh-action-sigstore-python@main that would be helpful. I will try to do a release anyway tomorrow but would be good to see that the issues have all been fixed (I believe we are testing them but as #257 showed, testing GitHub actions is pretty tricky).

[jku]

I believe this issue is resolved with 3.2.0 release