PYTHON-5980 Handle exclude-newer in the uv lock update action - #118
Conversation
371185f to
fc1ee44
Compare
There was a problem hiding this comment.
Pull request overview
This PR updates the python/uv-lock-update composite action to apply a default “exclude newer than 7 days” cutoff for uv lock --upgrade, with an exclude_newer input to override or disable that behavior, reducing the chance of immediately locking to freshly-published (and potentially yanked) releases.
Changes:
- Added a new
exclude_neweraction input (default:7 days) that is forwarded to uv viaUV_EXCLUDE_NEWER. - Implemented logic to not set
UV_EXCLUDE_NEWERwhen the input is empty (since uv rejects an empty-but-set value). - Updated README documentation to describe the new default cutoff and configuration options.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| README.md | Documents the new 7-day cutoff behavior and the exclude_newer override semantics. |
| python/uv-lock-update/action.yml | Adds the exclude_newer input and conditionally exports UV_EXCLUDE_NEWER before running uv lock --upgrade. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
python/uv-lock-update/action.yml:79
- When
exclude_neweris explicitly empty, this branch does not remove an inheritedUV_EXCLUDE_NEWERfrom the caller's job/workflow environment.uvwill still use that inherited cutoff instead of the repository'spyproject.toml/uv.tomlsetting, contradicting the documented empty-input behavior. Explicitly unset the variable in the empty branch.
if [ -n "$EXCLUDE_NEWER" ]; then
export UV_EXCLUDE_NEWER="$EXCLUDE_NEWER"
fi
| # rejects it when empty, so an empty input has to leave it unset rather | ||
| # than be passed through. | ||
| if [ -n "$EXCLUDE_NEWER" ]; then | ||
| export UV_EXCLUDE_NEWER="$EXCLUDE_NEWER" |
There was a problem hiding this comment.
Does uv parse the string false as a date/timestamp/duration?
There was a problem hiding this comment.
No, false is a special value. uv's --exclude-newer help says "Use false to disable exclude-newer", and that applies to UV_EXCLUDE_NEWER as well.
I checked against uv 0.12: with [tool.uv] exclude-newer = "2024-01-01" in
pyproject.toml, UV_EXCLUDE_NEWER=false uv lock --upgrade resolves cleanly and
the resulting lock records no cutoff at all. A value uv cannot parse fails the
step instead, so a typo like flase errors out rather than quietly disabling the
cutoff.
Conflict in README.md: mongodb-labs#118 documented the uv-lock-update action's new exclude_newer input in the Python section that this branch moved into python/README.md. Kept the split and ported mongodb-labs#118's wording into the moved section, which now matches main's text exactly.
Summary
Adds a 7 day cutoff on new releases in the uv lock update action, overridable through an
exclude_newerinput.Motivation
Prior to this change, a scheduled update would include every release the moment it lands, including one yanked hours later as broken or compromised. A week of distance means a bad release is usually withdrawn first.
Changes
exclude_newerinput, defaulting to7 daysand reaching uv asUV_EXCLUDE_NEWER. It takes anything uv's--exclude-newerdoes: a date, an RFC 3339 timestamp, a duration such as30 days, orfalseto disable the cutoff.UV_EXCLUDE_NEWERunset, so a repository can keep the cutoff in its own uv configuration. uv rejects the variable when it is set but empty, so this case has to be handled rather than passed through.Testing
Ran the resulting step against uv 0.12 both ways:
7 dayslocks withexclude-newer-span = "P7D", and an empty value locks with no cutoff recorded.