[mise-lock] chore: migrate CI to mise-action

[krukonshedul]

Summary

• Adds mise.toml ([tools] python = "3.10") and generates mise.lock, in the versioned lockfile_version = 1 format mise 2026.8.11+ requires.
• Replaces actions/setup-python in python-package.yml with step-security/mise-action, pinned to v4.2.4 (mise CLI 2026.8.12).
• docker-build.yml has no toolchain-install step, so it is left untouched.
• .gitignore now excludes .github/actions.lock.yaml.
• Regenerated .github/actions.lock.yaml via alflow.

Judgment call

• No .tool-versions or existing mise.toml was present. python-package.yml tests a matrix of Python versions (3.7/3.8/3.9/"3.10") rather than a single pinned version. To preserve that matrix coverage, the mise-action step overrides the tool version per job via its mise_toml input (python = "${{ matrix.python-version }}"), following the same override pattern already used elsewhere in the org (see app-b2c-api-gateway's update-ampli.yaml). The root mise.toml itself pins python = "3.10" (the newest matrix entry) as the default/lockfile version.

Test plan

• CI passes on this PR (python-package.yml matrix jobs all green)

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	github/​step-security/​mise-action@​6e96d2ffbc65c037f23c78818f2a339d6cf830f7

View full report

[dyl-sv]

Blocking bug: in .github/workflows/python-package.yml, the second commit (5bac3b8, "pin mise-action to 2026.8.12") tries to pin the mise-action version but adds it as a second with: key on the "Setup mise" step instead of merging it into the existing with: block:

- name: Setup mise
  uses: step-security/mise-action@6e96d2ffbc65c037f23c78818f2a339d6cf830f7 # v4.2.4
  with:
    version: '2026.8.12'
  with:
    mise_toml: |
      [tools]
      python = "${{ matrix.python-version }}"

This is a duplicate mapping key, which is invalid YAML.

Evidence this is currently broken on HEAD (5bac3b8):

• The workflow run for this exact head commit (run 32952604392, confirmed via API to be attached to PR #7 / this head SHA) has conclusion "failure", completed in 0 seconds, with GitHub's own message: "This run likely failed because of a workflow file issue." No jobs ran — the workflow file fails to parse.
• gh pr checks 7 doesn't even list a "Python package" check for the current head, because the workflow is unparseable and never registers a check run.
• I independently parsed the file with a lenient YAML parser to sanity-check the duplicate-key semantics: a lenient parser silently drops the first with: block (silently discarding the intended version pin), while GitHub Actions' stricter parser rejects the file outright. Either way, the stated intent of the commit ("Pins step-security/mise-action to v4.2.4 (mise CLI 2026.8.12)") is not actually in effect, and CI cannot run at all on the current head.

This is a new regression introduced by this PR (specifically the second commit), not pre-existing: master's prior "Python package" failures were ordinary test failures under the old actions/setup-python setup, a different failure mode than a workflow-file parse error.

Fix: merge into a single with: block, e.g.

with:
  version: '2026.8.12'
  mise_toml: |
    [tools]
    python = "${{ matrix.python-version }}"

Please fix and confirm a green run on the resulting head commit before re-requesting review.

[dyl-sv]

Re-verified from scratch on head SHA f874c93.

Good news: the original defect is fixed. The "Setup mise" step in .github/workflows/python-package.yml now has a single merged with: block (version + mise_toml), the workflow file is valid YAML, and it actually runs — no more "workflow file issue" / zero-jobs failure.

However, CI is still red on this head SHA, so it does not meet the bar of "real jobs run and pass":

• build (3.8): mise itself fails to install — Failed to install core:python@3.8: No GitHub artifact attestations found for python@3.8.20. mise's attestation verification (default-on in 2026.8.12) rejects this specific python-build-standalone release.
• build (3.9) and build (3.10): mise install succeeds, but tests fail at collection — ImportError: cannot import name 'url_quote' from 'werkzeug.urls'. The mise-managed environment resolves a newer Werkzeug than the previous actions/setup-python + pip cache did, and Flask's installed version is incompatible with it.
• build (3.7): tests run further but still fail — 4 failed, 194 passed, 15 errors in tests/webhooks_test.py (TimeoutError against the webserver plugin), likely a knock-on effect of the same dependency drift.

Only the non-build checks (Socket Security, StepSecurity Optional Checks) are green.

Please pin/resolve the Flask/Werkzeug versions (or add an upper bound) so the wsview import works again, and either pin a python-build-standalone release that has attestations for 3.8.20 or set MISE_PYTHON_GITHUB_ATTESTATIONS=false / python.github_attestations = false for that toolchain. Requesting changes until the 3.7-3.10 matrix is green.

[dyl-sv]

Re-verified from scratch on head 3956df1ae89d5bc69e73013ee73aa048b11110a6.

Both prior concerns are fixed, and this PR is now a large net improvement over master. For context, which changes how the remaining redness should be read: master's Python package workflow is 4/4 red and has been for months (latest master run 28650437268 — build (3.7) fails at Set up Python 3.7, and 3.8/3.9/3.10 all fail at Test on …). On this head, build (3.8) and build (3.10) are fully green and build (3.9)'s test step passes 213 tests. So I'm not going to hold this to "all green" when the baseline is zero green.

• The werkzeug pin (werkzeug==2.0.3) fixed the url_quote ImportError — 3.9 and 3.10 now collect and pass.
• MISE_PYTHON_GITHUB_ATTESTATIONS: false on the Setup mise step fixed the 3.8 attestation failure — build (3.8) is green end to end.

Two things still need a decision, and the first is a genuine defect rather than just CI redness:

1. Blocking: pyOpenSSL==26.2.0 silently drops Python 3.7 support of the shipped package. This isn't a CI-only pin — it's in setup.py's install_requires, so it's the dependency contract of the published errbot distribution. pyOpenSSL 26.2.0 requires Python >= 3.8, so the 3.7 leg can't even resolve it:

ERROR: Could not find a version that satisfies the requirement pyOpenSSL==26.2.0
       (from versions: 0.6, …, 25.3.0)
ERROR: No matching distribution found for pyOpenSSL==26.2.0

Meanwhile setup.py still carries "Programming Language :: Python :: 3.7" (line 146) and python-package.yml still lists 3.7 in the matrix. The PR is internally inconsistent: it claims 3.7 support in two places while making 3.7 uninstallable in a third. Pick one:

• keep 3.7 — use an environment marker, e.g. "pyOpenSSL==26.2.0; python_version >= '3.8'" plus a compatible lower pin for 3.7; or
• drop 3.7 — remove it from the matrix, drop the 3.7 classifier, and set python_requires=">=3.8".

Either is fine, but it should be a deliberate choice, and dropping a Python version is a bigger call than a chore: migrate CI to mise-action PR implies — worth calling out in the PR body if you go that way.

2. Non-blocking: Check Distribution (3.9) fails on a tox 3 → tox 4 path change, not on anything you did. tox.ini's dist-check env runs twine check {toxworkdir}/dist/*, but the newer tox that the mise-managed Python resolves builds the sdist to {toxworkdir}/.tmp/package/N/ instead:

dist-check: install_package> pip install --force-reinstall --no-deps \
    /home/runner/work/errbot/errbot/.tox/.tmp/package/2/errbot-9.9.9.tar.gz
dist-check: commands[0]> twine check '/home/runner/work/errbot/errbot/.tox/dist/*'
ERROR   InvalidDistribution: Cannot find file (or expand pattern):
         '/home/runner/work/errbot/errbot/.tox/dist/*'

Note the package is right there in the line above, just at a different path. This was never reachable on master (the 3.9 job died at Test on 3.9 first), so it's newly-exposed rather than a regression. Simplest fix is to build explicitly in that env — python -m build then twine check dist/* — rather than reaching into tox's internal work dir.

One cleanup while you're here: the new .gitignore entry for .github/actions.lock.yaml has no effect — this same diff modifies that file and it's still tracked at head, and .gitignore only applies to untracked paths, so it'll keep producing diffs. Same defect @kpiotr flagged on ion#514, where it was resolved by untracking the file. Also present on sidekiq_alive#13 and err-backend-slackv3#7, so worth doing consistently across the fleet.

Requesting changes on (1) only. Happy to approve with 3.7 still red if the answer is "3.7 is being dropped" and the classifier/matrix/python_requires are made to agree.