Skip to content

ci: stop Dependabot proposing Groovy majors that TinkerPop cannot take - #5534

Merged
robfrank merged 1 commit into
mainfrom
chore/dependabot-ignore-groovy-major
Jul 29, 2026
Merged

robfrank merged 1 commit into
mainfrom
chore/dependabot-ignore-groovy-major

Conversation

@robfrank

Copy link
Copy Markdown
Collaborator

What does this PR do?

Adds a single Dependabot ignore rule so Groovy major updates stop being proposed for the Maven reactor:

    ignore:
      - dependency-name: "org.apache.groovy:*"
        update-types: ["version-update:semver-major"]

Patch and minor updates are unaffected and keep flowing.

Motivation

Groovy's version is set by TinkerPop, not by ArcadeDB.

org.apache.groovy:groovy is declared in exactly one place, gremlin/pom.xml:106. No other module in the reactor depends on it. gremlin-groovy 3.8.1 is built against the Groovy 4.0.x line (TinkerPop 3.8.1's parent pom declares groovy.version 4.0.25), so Groovy 5 is a major break that cannot be adopted until TinkerPop itself moves.

That makes PR #4969 (4.0.325.0.7) structurally unmergeable rather than merely stale. It has been open since 2026-07-04 with 6 failing checks, and re-proposing it every week costs a PR slot and reviewer attention for an upgrade that cannot land.

Only majors are ignored, deliberately. ArcadeDB pins 4.0.32, which is ahead of TinkerPop's own 4.0.25, so the project is already taking 4.0.x patches on purpose. Those must keep arriving; this rule does not touch them.

Related issues

Supersedes #4969, which should be closed once this merges.

Does not affect org.apache.tinkerpop:gremlin-groovy, so the TinkerPop upgrade that would eventually unlock Groovy 5 still gets proposed normally.

Additional Notes

ANTLR is deliberately excluded from this rule, despite the identical TinkerPop coupling. This is the part worth reviewing carefully, and the reasoning is recorded as a comment in the config so it is not re-litigated later.

antlr4.version is declared per-module, with two different intents:

Module Version Why
gremlin/pom.xml:45 4.9.1 gremlin-language 3.8.1 ships a parser generated by the ANTLR 4.9.1 tool. ANTLR 4.10 changed the serialized ATN format (the BASE_SERIALIZED_UUID field present in 4.9.1's ATNDeserializer is gone in 4.13.2), so a 4.13 runtime cannot read a 4.9.1-generated parser.
engine/pom.xml:46 4.13.2 The engine's own grammar, independently on the newest ANTLR available.

Dependabot ignore rules match dependency coordinates, not modules or properties. Gremlin's frozen 4.9.1 sits below the engine's current 4.13.2, so any version range that blocked the Gremlin bump would also cover the engine's version and silently freeze it. That trades a small amount of noise for the loss of a signal we actually want.

PR #3235 should therefore be closed by hand rather than suppressed by config. Closing a Dependabot PR stops it re-proposing that same version; it only returns when a genuinely new ANTLR ships, and 4.13.2 is currently the newest (released 2024). That is roughly one PR every couple of years, and when it arrives it is a real signal for the engine.

Verification: the config parses, the maven entry is otherwise unchanged, no other ecosystem is touched, and the pattern was checked against the real coordinates:

MATCHES  org.apache.groovy:groovy              4.0.32 -> 5.0.7  (major, PR #4969)  -> ignored
MATCHES  org.apache.groovy:groovy              4.0.32 -> 4.0.33 (patch)            -> still proposed
no match org.antlr:antlr4-runtime              4.9.1  -> 4.13.2 (PR #3235)         -> untouched
no match org.apache.tinkerpop:gremlin-groovy   3.8.1  -> 3.9.0                     -> untouched

Longer term: the real unlock for both frozen dependencies is a TinkerPop upgrade. When TinkerPop moves to ANTLR 4.13 and Groovy 5, both bumps become trivially mergeable and this ignore rule can be dropped. That is worth a tracking issue against gremlin.version rather than two recurring Dependabot PRs.

Checklist

  • I have run the build using mvn clean packagenot applicable and not run. The diff is one file, .github/dependabot.yml; no source, no pom.xml, no build input changes.
  • My unit tests cover both failure and success scenariosno unit tests added. Dependabot configuration is not executable by the build. The equivalent evidence is the pattern-match check above.

Groovy's version is set by TinkerPop, not by ArcadeDB. It appears only in
gremlin/pom.xml (org.apache.groovy:groovy) and no other reactor module
depends on it. gremlin-groovy 3.8.1 is built against the Groovy 4.0.x
line, so Groovy 5 is a major break that cannot be adopted until TinkerPop
moves. PR #4969 (4.0.32 -> 5.0.7) has been unmergeable since July for
this reason.

Ignores majors only. ArcadeDB deliberately runs 4.0.32, ahead of
TinkerPop's own 4.0.25, so 4.0.x patch and minor updates keep flowing.

ANTLR shares the same TinkerPop coupling but is deliberately left out.
antlr4.version is declared per-module with two different intents: gremlin
pins 4.9.1 because gremlin-language ships a parser generated by the ANTLR
4.9.1 tool and 4.10 changed the serialized ATN format, while engine
independently tracks the latest 4.13.2 for its own grammar. Dependabot
ignore rules match coordinates rather than modules, and gremlin's frozen
4.9.1 sits below the engine's current 4.13.2, so any range blocking the
gremlin bump would silently freeze the engine too.
@mergify

mergify Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

  • Queue this pull request

@robfrank
robfrank merged commit b670cc8 into main Jul 29, 2026
10 of 12 checks passed
@robfrank
robfrank deleted the chore/dependabot-ignore-groovy-major branch July 29, 2026 08:46
@codacy-production

codacy-production Bot commented Jul 29, 2026

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Coverage ∅ diff coverage · -5.86% coverage variation

Metric Results
Coverage variation -5.86% coverage variation
Diff coverage diff coverage

View coverage diff in Codacy

Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (6de851d) 146712 108822 74.17%
Head commit (c270c91) 171643 (+24931) 117264 (+8442) 68.32% (-5.86%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#5534) 0 0 ∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@claude

claude Bot commented Jul 29, 2026

Copy link
Copy Markdown

Review: ci: stop Dependabot proposing Groovy majors that TinkerPop cannot take

Reviewed the one-file diff to .github/dependabot.yml and verified the claims against the repo. This is a clean, well-motivated change and I would happily merge it.

Verification (all confirmed against the tree)

  • org.apache.groovy:groovy is declared in exactly one place: gremlin/pom.xml:105-107, pinned to groovy.version = 4.0.32. No other reactor module declares it.
  • ANTLR split is real and matches the rationale: engine/pom.xml:46 = 4.13.2, gremlin/pom.xml:45 = 4.9.1, both using the same org.antlr:antlr4-runtime coordinate. This confirms the core argument for not adding an ANTLR ignore rule: a coordinate-level ignore would freeze the engine along with gremlin. That decision is correct, and documenting the reasoning inline is the right call.
  • Pattern org.apache.groovy:* with update-types: ["version-update:semver-major"] is valid Dependabot syntax, scoped to majors only, so 4.0.x patch/minor bumps keep flowing as intended.

One minor nit (non-blocking, doc accuracy only)

The inline comment says Groovy "appears only in gremlin/pom.xml and gremlin-it/pom.xml", but in gremlin-it/pom.xml the word "groovy" only shows up in a comment (line 76) describing what the shaded uber-jar bundles - there is no org.apache.groovy dependency declaration there. The PR description itself correctly states it is "declared in exactly one place." Since Dependabot only reacts to declared dependencies, and to keep the comment from contradicting the PR body, consider tightening the wording to note that gremlin-it only bundles (does not declare) Groovy via the shaded uber-jar.

Notes / suggestions

Scope / risk

  • Config-only, additive, single ecosystem block. No source, no pom.xml, no build inputs touched - so skipping mvn clean package and unit tests is appropriate; there is nothing executable to test. The pattern-match evidence in the description is the correct form of verification.

LGTM.

@codecov

codecov Bot commented Jul 29, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.42%. Comparing base (6de851d) to head (c270c91).
⚠️ Report is 28 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #5534      +/-   ##
============================================
+ Coverage     65.31%   66.42%   +1.11%     
============================================
  Files          1748     1702      -46     
  Lines        146712   139651    -7061     
  Branches      31356    30198    -1158     
============================================
- Hits          95827    92769    -3058     
+ Misses        37933    34296    -3637     
+ Partials      12952    12586     -366     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant