Upgrade gradle dependencies only if >=48h old#11293
Upgrade gradle dependencies only if >=48h old#11293sarahchen6 wants to merge 1 commit intomasterfrom
Conversation
4efc512 to
5d9229e
Compare
5d9229e to
355ced2
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 355ced273e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if published_at is None: | ||
| print(f"::warning file={relative_path}::{gav}: {reason} Skipping age check.") | ||
| continue |
There was a problem hiding this comment.
Enforce dependency-age policy when timestamp lookup fails
When resolve_gav_timestamp cannot determine a publish time, this branch only emits a warning and skips validation, so the updated lockfile is kept unchanged. In the current workflow (update-gradle-dependencies.yaml), no --metadata-file is provided, so any Maven Central outage/rate-limit or any dependency not indexed there will bypass the 48-hour gate entirely, which contradicts the stated policy of only upgrading dependencies old enough to pass the cooldown.
Useful? React with 👍 / 👎.
What Does This Do
Only upgrade gradle dependencies if they are at least 48 hours old. This PR specifically addresses the “Update Gradle dependencies” workflow. This follows #11215
Motivation
Require a 48-hour cooldown on external dependencies to reduce the risk of zero-day vulnerabilities.
Additional Notes
This PR was largely written by AI with my guidance on requirements and testing, followed by my review and tweaks for readability.
I added python tests for the scripts, but the actual changes need to land on
masterbefore the workflow can be tested because the workflow depends on anocto-ststoken that is only scoped to master.Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]
Note: Once your PR is ready to merge, add it to the merge queue by commenting
/merge./merge -ccancels the queue request./merge -f --reason "reason"skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.