casaroli opened a new pull request, #19681:
URL: https://github.com/apache/nuttx/pull/19681
## Summary
The documentation job installs its Python environment with `pipenv install`,
which does not honour the committed `Pipfile.lock`. Every run in the logs —
failing and passing alike — prints `Locking dependencies...` and `Updated
Pipfile.lock`, then installs from the set it has just re-resolved. Each
documentation build therefore takes whatever PyPI resolves that day rather than
what the lock file names.
On the evening of 2026-08-03 one of those resolutions produced a virtualenv
without `packaging`, and four unrelated pull requests failed identically,
before Sphinx had read a single file:
```
File ".../sphinx/extension.py", line 7, in <module>
from packaging.version import InvalidVersion, Version
ModuleNotFoundError: No module named 'packaging'
make: *** [Makefile:52: clean] Error 1
```
```
failure 08-03T23:37 feature/st7123-touch
failure 08-03T22:03 feature/mpu6050-drdy-interrupt
failure 08-03T21:30 fdpic-libelf
failure 08-03T21:30 arm-pic-r9
success 08-03T18:54 arm-pic-r9 <- same branch, three hours earlier
```
`pipenv sync` installs exactly what `Pipfile.lock` names and never
re-resolves, which is what the lock file is for. Nothing else about the job
changes.
The lock is complete enough to install from as it stands: it covers all
fourteen packages the `Pipfile` asks for, and it does contain `packaging`.
`pipenv install --deploy` was the other candidate. It refuses to run when
the lock does not match the `Pipfile` instead of silently re-resolving, which
is stricter and arguably more correct — but the two hashes do not currently
agree, so it would fail the job outright until someone regenerates the lock.
`sync` fixes the flakiness now without that. Happy to switch if maintainers
would rather have the strict form and a regenerated lock in the same PR.
## Why the trigger changes
The workflow ran only for changes under `Documentation/`, so a change to the
documentation build was never exercised by the build it changed. It now
triggers on `.github/workflows/doc.yml` as well.
That is what tests this PR: without it, a workflow-only change would report
no documentation build at all.
## Impact
CI only. No effect on any build, board or API.
Nothing is pinned that was not pinned before — determinism comes from the
lock file, not from freezing the `pipenv` version, and no other workflow in the
tree pins its pip installs.
## Testing
The documentation job on this PR is the test, and it exercises exactly the
changed file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
