Config file: Support Wildcards in directory

[blakemorgan]

Our repo doesn't have a pom.xml file at / but it does in multiple subdirectories (so /*/). Dependabot didn't recognize the wildcard in the directory name when I put that in the config file. Is it possible to get wildcards recognized in the directory value of the config file?

[greysteil]

Frustratingly, this is a bit more difficult on our backend than it sounds. The answer here is pretty similar to:

• Recursively Check for poms #2177

We'd like to support this, and it's on our roadmap (together with grouping projects), but it's a way off.

[bsideup]

Would be nice to have it!

Here is an example where it fails:
https://github.com/bsideup/liiklus/blob/09d16a867b93ca966d6200c6d62f646d0344065b/settings.gradle#L11

[alexf101]

I wrote a script that auto-generates Dependabot configs using globs 😅

Please feel free to use my awful hacks however you like until Dependabot/Github implement this feature properly.

https://gist.github.com/alexf101/b65cbfe7c5a61df7d925589a71d200cf

[jauderho]

+1 from me.

I have a dockerfiles repo with multiple directories representing different images being built. I was dismayed to find out that dependabot.yml only allows specifying one directory.

Even if we are somehow able to do the following would be a start

directory: |
/dir1
/dir2

[michaelmerrill]

Any update on where this is on the roadmap?

[blakemorgan]

For our teams, the Terraform support with Dependabot greatly increased the need for this feature. We have local modules storing common infrastructure for the environments, then a separate folder for each environment. Sometimes, because of weird dependencies, we have to have two folders for each environment. That's upwards of 10 folders for each project. It would be nicer to have one entry in the config file instead of 10.

[gjermundgaraba]

If someone would like a javascript hack as a workaround:

• handlebar template for dependabot file
• "fast-glob" all the different types you need and generate a new dependabot file:

fb.sync([
        `${repoRoot}/**/package.json`,
        `${repoRoot}/**/go.mod`,
        `${repoRoot}/**/pom.xml`,
        `${repoRoot}/**/Dockerfile`,
        // Stuff to ignore:
        `!${repoRoot}/**/node_modules`,
        `!${repoRoot}/**/vendor`])
        .map(mapItToAStructureYouWantToSendToHandleBar)

For monorepos, it is death trying to maintain the dependabot file by hand.

[dgokcin]

also interested in any sort of beta ✋

[taha-dekmak]

Also interested in beta ✋

[afzanjamalreach]

@abdulapopoola

Hopefully some time in April :), if you are interested in an early beta, that might be possible. cc: @carlincherry

We'd love beta access also

[neilime]

Hi, also interested of beta 👍

[kashifest]

Happy to check beta with Metal3-io

[adamlui]

Hey if you guys stop callng it beta then it could be treated more like an urgent matter requiring a final stable working implementation

[ascopes]

@adamlui I don't think the comments referring to version naming here are going to impact how the team manages their release schedule. If it is an urgent issue then more people need to upvote the GitHub issue itself.

That aside, people registering interest in using the release candidate versions means the feature gets more usage exposure sooner, allowing identification of bugs sooner.

Urgent or not, it needs to be tested properly. I'd much rather have something that works properly and is battle tested than something that raises erroneous MRs on my projects.

[lucacome]

I noticed that dependabot started using a new format for the title of grouped updates, like

Bump the actions group across 1 directory with 5 updates

Does it mean that support for multiple directories is almost here? 😄

[burik666]

@lucacome Dependabot grouped security updates generally available

[adamlui]

@adamlui I don't think the comments referring to version naming here are going to impact how the team manages their release schedule. If it is an urgent issue then more people need to upvote the GitHub issue itself.

@ascopes you can think what you want, doesn't change the fact if a million ppl complain about some bug in my software I will absolutely treat it less urgent if everyone keeps expressing interest in trialing some "beta" (this is merely common human psychology, your demand ppl upvote issue does not affect it)

That aside, people registering interest in using the release candidate versions means the feature gets more usage exposure sooner, allowing identification of bugs sooner.

False, again, if something is touted as a beta feature, there is less incentive to treat it as an issue instsead (features are bonuses, issues are not)

Urgent or not, it needs to be tested properly. I'd much rather have something that works properly and is battle tested than something that raises erroneous MRs on my projects.

This is a poor justification for calling something beta (you can test patches without calling them beta)

[adamlui]

You can get mad but if you reflect on how utterly simple the logic behind parsing an array of dirs should be yet it's somehow still not implemented, everyone hyping it up as some excusable "beta feature" instead of the simple bug fix it should've been cannot possibly be helping the timeline

[Dreamsorcerer]

Nor is complaining if it's so easy for you to implement... code's right there under the 'Code' tab.

[adamlui]

Knew someone would say something like you. GitHub programmers are paid six figures, we are not paid to do their job, stop trying to excuse laziness (it's been 5 years literally wake up)

[adamlui]

(it is very easy but don't ever code for free for software that is maintained by paid coders unless your time is utterly valueless or you enjoy lazy others ignoring issues for years getting raises/promotions off your unpaid hard work which is just not smart, no other way to put it)

[abdulapopoola]

Multi-dir configuration is now in public beta!; open to hearing your thoughts as you try out the beta!!

Tagging @carlincherry

[mhemmings]

@abdulapopoola @carlincherry Amazing, thanks!

How does this work with Github Actions, since they have slightly different behaviour with regards to directory? Does it fix the ability to update composite actions? (See https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#github-actions)

i.e. I'm hoping the following should now work:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directories:
      - "./github/workflows"
      - "./github/actions/composite-a"
      - "./github/actions/composite-b"
      - "./github/actions/composite-c"
    schedule:
      interval: "weekly"

[blu3mania]

Multi-dir configuration is now in public beta!; open to hearing your thoughts as you try out the beta!!

Tagging @carlincherry

Question, is the beta available to Enterprise Cloud repos?

[lucacome]

I was trying this out and it doesn't seem to work.

Well, it did group all the different directories in the dependabot tab, but then when there was a dependency update it only updated the first go.mod file in the directories list and not the second one.

[cpswan]

I'm seeing similar problems to @lucacome :(

Now rather than getting 4 PRs in one day I'm going to see 4 PRs over 4 days (for the same dependency change), which isn't an improvement on toil, and makes things worse for timely updates.

What's supposed to happen here is all 4 PRs rolled into one.

It makes me wonder if anybody actually tested the 'beta'?

[carlincherry]

How does this work with Github Actions, since they have slightly different behaviour with regards to directory? Does it fix the ability to update composite actions? (See https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#github-actions)

@mhemmings I would expect this to work with composite actions. Did you experience different behavior?

You can try using multi-directory support and grouping rules; that should work to update composite actions. cc @abdulapopoola

[carlincherry]

Question, is the beta available to Enterprise Cloud repos?

@blu3mania yes, this beta should be available to Enterprise Cloud repos!

[carlincherry]

I was trying this out and it doesn't seem to work.

Well, it did group all the different directories in the dependabot tab, but then when there was a dependency update it only updated the first go.mod file in the directories list and not the second one.

@lucacome thank you for raising this to the team; this is unexpected behavior and we've created a bug which our team will prioritize fixing soon.

cc @abdulapopoola

[carlincherry]

@cpswan do you have grouping enabled? cc @abdulapopoola

[adamlui]

I was trying this out and it doesn't seem to work.
Well, it did group all the different directories in the dependabot tab, but then when there was a dependency update it only updated the first go.mod file in the directories list and not the second one.

@lucacome thank you for raising this to the team; this is unexpected behavior and we've created a bug which our team will prioritize fixing soon.

cc @abdulapopoola

@carlincherry since you appear to have the higher authority to prioritize bugs, can this one be added #9071 as it is quite stale and cost me endless hours of extra manual labor that should not be necessary (dependabot is supposed to automate, not create more work than just typing npm update)

It should be quite easy to fix too, it's happens most often when package.json isn't root so the logic for detecting nested manifests should be revised to rely on "node_modules" as an ancestor dir instead