Hi folks, I did some tweaks to try to reduce the manual steps involved when we use the dependencyUpdates task and track dependency version changes via Jira issues. This doesn't impact dependabot driven changes. We may move to more automation like dependabot as we move forward, but this covers the existing dependency upgrade workflow in the meantime.
Cheers, Paul. TL;DR: You now get cleaner and more information which may help you, or you can ignore. ---------------- What `./gradlew depUp` does now Alongside the normal list of outdated dependencies, the output includes a few extras aimed at making bumps easier to triage: - A hint line per outdated dep showing its best guess at the most recent related commit and a clickable Apache Jira link, so you can jump straight to the last ticket for that dependency. - A list of candidate versions that were skipped because they require a later JDK than we currently build against. - A list of dependencies we pin to a specific version line (e.g. Groovy 5.0.x for baseline comparisons, JUnit 5.x for groovy-test-junit5) where a newer in-line update has appeared to remind us to bump the pin. False positives are now avoided - Shiny-but-unusable versions that require a newer JDK no longer appear as "available." - Dependencies we intentionally keep on an older version line don't get noisy "upgrade to major version X" hints. - Groovy's own artifacts (both `org.apache.groovy` and `org.codehaus.groovy`) don't surface confusing self-referential commits as bump history. (These exist for binary compatibility and performances tests but we don't want to upgrade them.) Extra info you get - Latest related commit + Jira link for each bump candidate, so duplicating/linking the old ticket is one click. - Visibility into what got filtered and why. - Early warning when a pinned-version line drifts behind its latest patch release. Caveats - The commit/Jira match is a simple pattern search, so an occasional result may not be the exact bump you expected; the guessed commit in gits "--oneline" format is shown so you can usually tell at a glance if it hit a false positive. - The JDK check reads the candidate's own POM only, so some deps that inherit their JDK requirement from a parent can still slip through and fail at build time. - An extra ~30 seconds per run for the lookups. - It's still a manually-run task, not wired into CI so no impact for other tasks.
