Release
v3.3.0
watchtowerFailed runs now leave a visible record: one issue in your repository describing the latest failure, with the log, the affected dependencies and the dependency graph — while the job itself fails exactly as before. Also fixes three problems reported from customer merge requests: a merge request addressed to Argus's own staging file instead of your pom.xml, a still-needed BOM pin removed and re-added in one diff, and Jetty modules pinned individually at versions that cannot resolve together.
Highlights
- 01
One issue per project when a run fails
When an Argus run fails, the CI job fails exactly as it always did — and Argus now also keeps a single argus-labelled issue in the repository describing the latest failure: the error, an inline tail of the failing build log, which dependencies are affected at which resolved versions, the dependency-graph picture, and the full logs as attachments. Repeat failures rewrite the same issue rather than opening new ones, and a successful run closes it. On by default; switch off with the failure_issues input.
- 02
No more remove-and-re-add churn on BOM pins
A customer merge request said a BOM pin was no longer needed while the same change re-added it at a higher version. Argus judged exposure by advisory ID alone, and one advisory often covers several artifact families — so a pin that was still steering resolution looked disposable. Exposure is now judged by where an advisory actually lands: the coordinate and the version your build resolves. The pin stays, is upgraded in place, and the merge request tells one coherent story.
Full notes
Added
- Failure issues: one argus-labelled issue per project with the latest failure, log tail, affected coordinates, dependency-graph SVG, and attached evidence logs; rewritten on repeat failures, closed on success, enabled by default (failure_issues input / ARGUS_FAILURE_ISSUES).
- An end-to-end regression for the full failure-issue lifecycle, verified to fail without the feature.
- The coupled-family registry is now verified against the published BOMs on every run of the suite: each entry must name groups its BOM actually governs, and every group a BOM governs must be claimed. This caught an incomplete Jetty entry that would have kept six module groups fragmenting.
Fixed
- A run that both cleans up a spent override and publishes now commits your pom.xml. Previously it addressed the merge request to Argus's internal staging file (.argus-cleaned-<n>.pom.xml), creating that file and leaving pom.xml untouched, so the merge request fixed nothing. Reported from a customer merge request.
- A load-bearing BOM import is no longer released and re-added in one merge request: exposure is judged per coordinate and resolved version against the real dependency graph, not per advisory ID. Reported from a customer merge request.
- Advisories that name a fix for one artifact family and none for another are judged by the family they land on.
- Jetty, gRPC and Spring Security are now coupled families governed by their BOMs, so several vulnerable members consolidate into one import at the highest fix version instead of per-module pins at mixed versions. Reported from a customer merge request that pinned jetty-security 12.1.10 beside jetty-util 12.1.9 — a mix Maven's own upper-bound enforcement rejects. Jetty's ee10/ee9/ee8 lines each have their own BOM and are handled separately.