Conversation
doc/en/getting-started.rst
Outdated
|
|
||
| $ pytest --version | ||
| pytest 9.0.0 | ||
| pytest 9.0.1.dev17+g0fa11ae3f.d20251111 |
There was a problem hiding this comment.
@RonnyPfannschmidt we use the SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST trick to force the version (#8134), do you know if this is still supposed to be working?
There was a problem hiding this comment.
It's still in the stable doc: https://setuptools-scm.readthedocs.io/en/stable/config/#environment-variables
There was a problem hiding this comment.
Can this be due to https://github.com/pytest-dev/pytest/pull/13841/files#diff-ef2cef9f88b4fe09ca3082140e67f5ad34fb65fb6e228f119d3812261ae51449R98 being built in a separate environment where set_env on [testenv:regen] doesn't apply?
Try setting it in a [pkgenv] section as follows:
https://github.com/ansible/awx-plugins/blob/5b5f2eb1baa62d8d12805cf8da7c076aee9d1b3e/tox.ini#L142-L151
There was a problem hiding this comment.
The diff for tox c -e .pkg before and after 68016f0 is
--- pre-cutoff-config-.pkg.log 2025-11-11 18:34:47.680413742 +0100
+++ cutoff-config-.pkg.log 2025-11-11 18:34:55.967007776 +0100
@@ -2,7 +2,7 @@
type = Pep517VirtualEnvPackager
set_env =
PIP_DISABLE_PIP_VERSION_CHECK=1
- PYTHONHASHSEED=3427332812
+ PYTHONHASHSEED=1574684877
PYTHONIOENCODING=utf-8
PYTHONWARNDEFAULTENCODING=1
_PYTEST_TOX_DEFAULT_POSARGS=
@@ -83,4 +83,4 @@
config_settings_build_editable = None
fresh_subprocess = True
deps =
-# !!! unused: commands, description, extras
+# !!! unused: commands, description, extras, package, wheel_build_envThere was a problem hiding this comment.
And it does contain
pass_env =
SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTESTin both cases.
There was a problem hiding this comment.
The last release that didn't have a generated version in the patch was v8.4.2 @ #13696. In the CI log, it's visible that it also used a Git-derived on the tox level — https://github.com/pytest-dev/pytest/actions/runs/17435825368/job/49505262303#step:5:93:
regen: install_package> python -I -m pip install --force-reinstall --no-deps /home/runner/work/pytest/pytest/.tox/.tmp/package/3/pytest-8.4.2.dev21+g89905381a.d20250903.tar.gzHowever the regendoc invocation used the requested version. It was using tox v4.29.0 and newer runs use tox v4.32.0. The rest of the dep tree is the same.
There was a problem hiding this comment.
I confirmed that using tox==4.29.0 does not have this problem.
There was a problem hiding this comment.
Apparently, I can't reproduce this with SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST=9.0.1 python -Im tox r -e regen even with tox==4.32. So it's the SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST=9.0.1 tox r -e prepare-release-pr --notest invocation that might not be passing the var into regen.
There was a problem hiding this comment.
@nicoddemus I triggered the workflow to test #13933 and it apparently updated this PR. I didn't anticipate this but on the bright side — we now do know that it works. I'm going to merge the fix in, so it's absorbed properly and delete the experimental branch release-experiment/pr-13933 too.
github-actions
bot
force-pushed
the
release-9.0.1
branch
from
c176be5 to
126c7fa
Compare
|
@nicoddemus once #13935 is in, we should probably trigger pre-release again so it originates from a proper branch. |
There was a problem hiding this comment.
webknjaz
dismissed
nicoddemus’s stale review
This concern has been resolved by #13935.
|
I've triggered https://github.com/pytest-dev/pytest/actions/runs/19277570192/job/55121005018 — it will update this PR shortly. |
github-actions
bot
force-pushed
the
release-9.0.1
branch
from
126c7fa to
9e5fba9
Compare
github-actions
bot
force-pushed
the
release-9.0.1
branch
from
9e5fba9 to
34592e2
Compare
|
Looks like the release script doesn't handle existing PRs gracefully: https://github.com/pytest-dev/pytest/actions/runs/19277639565/job/55121223740#step:5:4792. It does push the branch but still attempts to create a PR which fails. Instead, it should try updating the PR description, if applicable or just do nothing.. |
|
Thanks a lot @webknjaz for all the digging and ultimately finding a solution and merging it!
I agree, but for now I will just close this PR and start from scratch. |
3 participants
Created by the prepare release pr workflow.
Once all builds pass and it has been approved by one or more maintainers, start the deploy workflow, using these parameters:
Use workflow from:release-9.0.1.Release version:9.0.1.Or execute on the command line:
gh workflow run deploy.yml -r release-9.0.1 -f version=9.0.1After the workflow has been approved by a core maintainer, the package will be uploaded to PyPI automatically.