https://gradle.com/ logo
Join Slack
Powered by
dependabot sucks with gradle because it doesn't kn...
# community-support
c
dependabot sucks with gradle because it doesn't know that just because something is in libs.versions.toml doesn't mean it's used. It also doesn't handle locks... All of that said, does anyone have a workflow either using dependabot or getting its message isn't their commits?
c
have you tried using the Gradle dependency submission action to submit the resolved set of dependencies to GitHub?
c
yes, but see above question about when to submit it... also just submitting dependencies doesn't make the PR's merge-able or give good commit messages/changelogs for releases
my current is that I have a job that runs and updates my dependencies and if it passes, it merges things back to main
but it's very light on the commit message, so it's not great for a release changelog
also, it does all the deps for the week in a single commit (which is likely large when spring boot updates anyways, even if I didn't just do everything)
so this is a commit message/changelog problem
c
you can configure dependabot to run on branches other than main, if that is your goal (to PR into release branches). Ditto with the grouping - by default it will do a PR-per-dependency-update, unless you configure grouping. Haven’t had any issues with the commit/PR messages, they sufficiently indicate the dependency updates.
c
sure, but dependabot's pr's are bad
they would literally break 100% of the time
c
Not finding that at all - have dozens of repos that generate dependabot PRs weekly without issue.
c
and you use locks? and you have dependencies in your libs.versions.toml that aren't actually used in your code?
because the last time I checked it will fail to update locks
and it will report on old dep versions in libs.versions.toml even though the dependencies aren't used
not sure what it would even do if I didn't have a libs.versions.toml and instead pulled those catalogs from an external source
c
the latter, yes. No locks. Sounds like you are looking for this enhancement. For a similar issue (dotnet dependencies - lock files) we wrote a GH action to update the locks on the PR branch so they didn’t error out.
if the deps aren’t used - what’s the issue? Update them along with everything else, or remove them.
c
I've already voted for said issue 😉
👍 1
I should say, yes I know about that issue, that's not news to me
👍 1
because I copy around my libs.versions.toml to other repos so I don't have to be constantly adding spring deps
or forget which dependencies I used elsewhere
my libs.versions.toml is 132 lines
most of those are used
but imagine I have mockito in there, and I"m not using mockito yet, and the dependency version goes stale
c
still not seeing the issue - if there deps are in there, why not just update them? Alternately, you could configure dependabot to ignore them.
c
because, it's not a priority
I have better things to do than update an unused string that will eventually just get copied back in
it's a software flaw on their end to use that file
c
sure, but if you group dependency updates they’re mixed in with others and don’t cause extra PRs.
c
in any sense, locks will still be broken
c
yes, though you can readily automate the regeneration of lockfiles when a dependabot PR is opened.
c
locks and the recursive output of dependencies are the correct sources of the truth
so there's a way to have all of these done as 1 PR and then regenerate the lockfies in that PR? which I can then automerge after tests are done
c
Yes. You can configure dependabot to group all the Gradle updates (or group by coordinates, or group by major/minor/patch updates - whatever works). Then you add another workflow triggered on a PR creation (with a condition to check that its a dependabot Gradle PR) to run the Gradle command to update locks & push the lock files back to the PR branch.
e.g.
Copy code
- package-ecosystem: "gradle"
    directory: "/"
    commit-message:
      prefix: "chore"
    ignore:
      - dependency-name: "*"
        update-types:
          - "version-update:semver-major"
      - dependency-name: "org.springframework*"
        update-types:
          - "version-update:semver-minor"
      - dependency-name: "org.jetbrains.kotlin*"
        update-types:
          - "version-update:semver-minor"
    groups:
      gradle-updates:
        update-types:
          - "patch"
          - "minor"
    schedule:
      interval: "weekly"
      time: "06:00"
      timezone: "Canada/Pacific"
c
and if I did this is the "dependency submission" action still needed?
c
The dependency submission action doesn’t affect updates, only security vulnerability checking. Without the dependency submission action GitHub doesn’t know about resolved versions / transitivie dependencies.
e.g.
Copy code
# <https://github.com/gradle/actions/tree/main/dependency-submission>
    - name: "Generate and submit dependency graph"
      if: ${{ inputs.java-version && github.ref == 'refs/heads/main' && hashFiles('gradlew') != '' && inputs.enable-dependency-graph-submission == 'true' }}
      uses: "gradle/actions/dependency-submission@dbbdc275be76ac10734476cc723d82dfe7ec6eda" # v3.4.2
      env:
        DEPENDENCY_GRAPH_EXCLUDE_PROJECTS: "^:(build-logic|buildSrc|.*[Tt]test.*)"
        DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS: ".*[Tt]est.*Classpath"
c
well, maybe I'll have to play around with it some more, if the PR can be used to fix my locks... before getting merged
ideally squash merged
👍 1
and auto merged. I've no interest in clicking a button once a week
c
yes, have other github actions to auto-approve and auto-merge Dependabot PRs that are only patch releases, works well.
Copy code
name: Dependabot auto-approve
on: pull_request

permissions:
  pull-requests: write
  contents: write

# <https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions>
jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      # <https://github.com/dependabot/fetch-metadata>
      - name: Dependabot metadata
        id: dependabot-metadata
        uses: "dependabot/fetch-metadata@5e5f99653a5b510e8555840e80cbf1514ad4af38" # v2.1.0

      - name: Automatically approve & merge Dependabot patch PRs
        if: ${{steps.dependabot-metadata.outputs.update-type == 'version-update:semver-patch' && steps.dependabot-metadata.outputs.package-ecosystem != 'nuget'}}
        run: |
          gh pr review --approve "$PR_URL"
          gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{ github.token }}
c
yeah, I've got a setup that does autom merge now
would just need to work in this
c
There’s some stuff here that we based dotnet/nuget lockfile automation off of (we didn’t use the slashcommands, used pull_request trigger much like the auto-approve above).
We sidestep lock files by disallowing dynamic versions entirely, and disallowing snapshots for CI builds.
Dependency locking makes sense only with dynamic versions. It will have no impact on changing versions (like 
-SNAPSHOT
) whose coordinates remain the same, though the content may change. Gradle will even emit a warning when persisting lock state and changing dependencies are present in the resolution result.
Copy code
configurations.all {
                resolutionStrategy {
                    // force latest.release (and other dynamic versions) to refresh
                    // this allows for emergency changes, like realigning artifact versions with CVEs
                    cacheDynamicVersionsFor(1, TimeUnit.HOURS)

                    // snapshots
                    cacheChangingModulesFor(0, TimeUnit.MINUTES)

                    // we don't allow dynamic versions; dependabot provides explicit updates
                    if (!allowDynamicVersions) {
                        failOnDynamicVersions()
                    }

                    // prevent snapshots from being used in CI builds
                    if (isCiBuild()) failOnChangingVersions()
                }
            }
c
any chance you know of a way to force dependabot to run immediately? in order to test such a workflow
c
Yes. AFK atm so from memory - in repo insights -> dependency graph, within there you can invoke dependabot
c
well this is fun... updater | +------------------------------------------+ updater | | Dependencies failed to update | updater | +--------------------------+---------------+ updater | | org.assertj:assertj-core | unknown_error | updater | | org.immutables:bom | unknown_error |
that aside though... not certain how this would trigger the workflow job if there aren't any updates
heh, it occurs to me this approach has another fundamental flaw. It's not going to work if I ever externalize my version catalogs because dependabot doesn't know how to gradle properly
because gradle has never made doing this easy
gradle making the easy thing hard...
I'd report this as a bug to gradle but I'm confident it already exists
3 Views
Open in Slack
PreviousNext
Powered by