Upgrade gradle dependencies only if >=48h old#11293
Conversation
sarahchen6
added
tag: no release notes
sarahchen6
force-pushed
the
sarahchen6/implement-48h-cooldown-for-gradle-dependencies
branch
from
4efc512 to
5d9229e
Compare
sarahchen6
force-pushed
the
sarahchen6/implement-48h-cooldown-for-gradle-dependencies
branch
from
5d9229e to
355ced2
Compare
sarahchen6
requested review from
AlexeyKuznetsov-DD and
amarziali
and removed request for
a team
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
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".
|
Marking as draft, as I re-review |
| "validate-lockfiles", | ||
| "--baseline-dir", str(baseline_dir), | ||
| "--current-dir", str(current_dir), | ||
| "--metadata-file", str(metadata_file), |
There was a problem hiding this comment.
what are the use case in which the metadata are missing? How updating will look like ? (i.e. manual?)
Maintaining this looks uncomfortable but I'm maybe missing context on this switch
There was a problem hiding this comment.
oh good catch! At some point, I meant to add an "override" option via this metadata file path, for example if the artifact wasn't found on Maven Central, but this is unused now, so I'll remove it... Instead there's an automatic retry to get the artifact to hopefully address the case there is infra flakiness.
There was a problem hiding this comment.
Ah sorry, a correction -- the --metadata-file is still used in these python tests to pass in timestamp values, but it's not used in the actual workflow
| --label "tag: dependencies" \ | ||
| --label "tag: no release notes" \ | ||
| --body "$(cat <<'EOF' | ||
| --body "$(cat <<EOF |
There was a problem hiding this comment.
is that potentially a security issue? Before the EOF heredoc was quoted and everything was treated as a literal string. Unquoting it looks like it will expand everything inside (and also run commands). If the body contains things from an external source (like GAV data that's coming from maven) it might inject stuff in my opinion. A safer option is keeping the heredoc quoted and use an ENV variable.
env:
PR_SUMMARY: ${{ steps.validate-lockfiles.outputs.summary }}
run: |
gh pr create --body "$(cat <<'EOF'
...
${PR_SUMMARY}
EOF
)"
There was a problem hiding this comment.
😲 It seems I have to keep the heredoc unquoted, otherwise ${PR_SUMMARY} will not expand either, but having this variable expansion rather than the inline ${{ }} shell execution is still safer. Updated in afc08da. Thanks!
| self.assertEqual(result.returncode, 0, result.stderr) | ||
| outputs = self.parse_outputs(result.stdout) | ||
| self.assertEqual(outputs["reverted_files"], "0") | ||
| self.assertEqual((current_dir / "module/gradle.lockfile").read_text(encoding="utf-8"), current_content) |
There was a problem hiding this comment.
Just curious, why stderr provided in first self.assertEqual(result.returncode, 0, result.stderr), not not in others? Looks a bit inconsistent, I think all asserts should follow some pattern.
There was a problem hiding this comment.
Sounds good! Looks like only the first test was reporting to stdout instead of stderr, but fixed in dad40c4
| metadata={}, | ||
| ) | ||
|
|
||
| self.assertEqual(result.returncode, 0, result.stderr) |
There was a problem hiding this comment.
nit: if returncode is a Python way? Should it be retrun_code ?
There was a problem hiding this comment.
Yes returncode is part of Python's stdlib naming, I believe here: https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess.returncode
| GRADLE_VERSIONS_URL = "https://services.gradle.org/versions/all" | ||
| MAVEN_SEARCH_URL = "https://search.maven.org/solrsearch/select" |
There was a problem hiding this comment.
Just curious if it worth to investigate to use our DD Magic Mirror? Using external repos can easily lead to throttling.
There was a problem hiding this comment.
Hm I think because this workflow does few queries (IIUC one query per changed version) and is only trying to pull metadata, not artifacts, we should be okay. We can reconsider if we see problems in the future?
3 participants
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.