PSA: GitHub Dependabot now supports Julia

Tooling
1

GitHub’s Dependabot now supports Julia.

i.e. A standard .github/dependabot.yml file can now look like this to keep both github actions and julia deps up to date:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "julia"
    directory: "/"
    schedule:
      interval: "weekly"
    # groups: # uncomment to group all julia package updates into a single PR
    #   all-julia-packages:
    #     patterns:
    #       - "*"

Dependabot has some benefits over CompatHelper:

  • PRs will have their CI run automatically without manual interaction
  • Any checked-in manifests will be updated, or if that fails the resolver errors will be shown directly in the PR body
  • Workspaces are supported. Just set the directory: field like normal to the root where the main Project.toml is, and the sub-projects will be handled automatically. An example PR can be seen here
  • Dependabot can tie into security/CVE reporting

Keeping test/, docs/ etc. updated

If you have test, docs or other subdirectories setup with environments, it’s recommended to use the new workspaces feature (1.12+) to tie them together, which will work with the simple single directory: "/" configuration that the main example above gives. See the [workspaces] docs for more information on workspaces.

If you would rather not use workspaces, you can specify a list of directories, but note that the update for a single dependency will be opened in individual PRs, and thus may not fully test the change due to resolver conflicts between the environments. (workspaces make coordinating all that a lot easier).

Multi directory config example 
version: 2
updates:
  - package-ecosystem: "julia"
    directories: # Location of Julia projects
      - "/"
      - "/docs"
      - "/test"
    schedule:
      interval: "weekly"

Current limitations

  • Dependabot doesn’t yet support custom julia package registries, but there is work in progress to fix that.
  • Dependabot runs on 1.12, so any manifest changes will be done from 1.12, irrespective of which version they were resolved with. Work is active in Pkg & juliaup to make it easier for the julia version of the manifest to be respected, which dependabot will then use.
  • The CVE reporting side of dependabot requires a little more infrastructure on the github side julia ecosystem support · Issue #1689 · github/advisory-database · GitHub

Thanks to those who helped with the beta period that was announced in November

Please feel free to suggest changes to this summary.

27 Likes
Monorepo [workspace] structure
2

Just to be clear, from the Dependant doc you linked:

Dependabot consists of three different features that help you manage your dependencies:

-    Dependabot alerts: Inform you about vulnerabilities in the dependencies that you use in your repository.
-    Dependabot security updates: Automatically raise pull requests to update the dependencies you use that have known security vulnerabilities.
-    Dependabot version updates: Automatically raise pull requests to keep your dependencies up-to-date.

The function that is implemented for Julia, and that replace CompactHelper, is the 3rd one (up-to-date dependencies), right?

3

Correct. For the first two please +1 on this issue julia ecosystem support · Issue #1689 · github/advisory-database · GitHub

4

Congrats on the hard work!
Can I suggest showing how test and docs dependencies can be taken into account by dependabot? This may be the most important missing piece in the provided example.

2 Likes
5

:backhand_index_pointing_down:

6

Sorry, I should have been clearer: I was referring to the following setup

    directories: # Location of Julia projects
      - "/"
      - "/docs"
      - "/test"

as being a worthy inclusion in the default example above instead of

    directory: "/"
1 Like
7

With a single directory and the workspace you get a single PR, instead of 3 separate.

2 Likes
8

Thanks. I updated the OP to make that all clearer.

1 Like
9

So with below in mind, you probably don’t want to do this then?

10

From my perspective it does seem like the better way to handle multiple sub projects, but it’s a new feature so there might be some unknown issues

11

My perspective was shaped by DifferentiationInterface.jl, where I absolutely cannot use workspaces unless I want to instantiate an environment containing every AD backend at once, including outdated ones which would severely restrict compatibility of other packages. More generally, workspaces are not ideal whenever there are subprojects with (a) wildly different or (b) very numerous dependencies.

12

Do you know where I can report bugs? E.g. this PR updated compat entries that were already included: Bump the all-julia-packages group across 1 directory with 2 updates by dependabot[bot] · Pull Request #6 · JuliaPluto/BetterFileWatching.jl · GitHub

13

Start the issue with julia:

3 Likes
14

That should be fixed now. Thanks for the report (and review!)