Ignore manifests in specific subdirectories

[chenrui333]

I have some monorepo in monorepo setup, but I do not want the dependebot scan a sub monorepo folder.

[dhowe]

Need to generally be able to specify sub-folders to ignore
Really annoying

[jirikrepl]

@jurre I think this would be quite nice. I also have a test folder with some old abandoned test framework. It has its own package.json. Depandabot is quite crazy about it, even it is not a production code.

[frederikheld]

+1 for this feature! I have exactly the same use case as @jirikrepl and would be very happy if I could exclude specific sub directories.

There's a discussion about this on SO already: https://stackoverflow.com/questions/65275433/can-i-exclude-directories-from-github-dependabot

[nicojs]

+1 here. In https://github.com/stryker-mutator/stryker-js, we've defined 40+ end to end tests in the /e2e directory. We also want to make sure StrykerJS works with older versions of test runners, so we have a test for karma-old-version, mocha-old-version, etc.

Now I've noticed that the old version is not so old anymore, since dependabot came a long and it got merged automatically 😢.

[nickgerace]

This feature would be great! Some monorepo refactors use outdated code in a sandboxed directory, and dependabot can be annoying when that code is very much dead (and intentionally so). Yes, you can/should also use a branch/tag, but not everyone prefers to do so.

[douglasg14b]

Not being able to ignore directories is quite annoying.

I have some legacy code in legacy directories, that is only used for reference purposes. It never runs anywhere. But I'm slammed with constant alerts & PRs for it.

[Dr-Electron]

We have the same problem. We have a documentation folder with dependencies that really don't need to be checked. Ignoring folder would really be a great and needed feature

[himynameisdave]

Yeah this seems like a real basic configuration option, sad to see that it is not implemented. Happy to help add this if anyone knows where I should get started!

[mcobzarenco]

Also on a monorepo and we have a directory where we have some hiring tests, currently 300 alerts from dependabot, all in recruitment package.jsons..

[nicojs]

The strangest thing. I've changed our dependabot configuration to only scan the /packages directory:

version: 2
updates:
  - package-ecosystem: npm
    directory: '/packages'

But now it isn't searching any of our packages (and apparently hasn't been since February, which is why users are reporting issues 😢).

Can anyone explain what's going on? Apparently using directory: '/' includes child directories, but directory: '/packages' does not?

[BradHarris]

@nicojs could you try directory: './packages'? I wonder if dependabot is somehow looking for /packages in the root of the filesystem.

[ChristianZaccaria]

I have a workaround that suits my use case, hopefully this could help others.
Use case:

project-root/
│
├── pyproject.toml      # Bump dependencies here
├── poetry.lock         # Bump dependencies here
└── other-dir/          # Another directory in the root, containing other files
    ├── requirements.txt # Exclude this file
    └── ...

I was required to only bump dependencies for poetry.lock and pyproject.toml files which are files located in the root directory. The issue is that there is another directory which contains a requirements.txt file I wish to exclude.
I used:

  - package-ecosystem: "pip"
    directory: "/"

The above includes the undesired requirements.txt file. However, I noticed that the directory option tracks recursively to only one level. Meaning, after moving the requirements.txt file to its own directory, it's no longer included for dependency bumps.

project-root/
│
├── pyproject.toml      # Bump dependencies here
├── poetry.lock         # Bump dependencies here
└── other-dir/          # Another directory in the root, containing other files
    ├── requirements # directory
               └── requirements.txt # excluded from dependabot.

[rwlodarczyk-xealth]

👋 Hey, I'm the Product Manager for Dependabot. Here's what's up:

This particular feature is not currently scheduled on our roadmap.

HOWEVER

We are doing some work around directory targeting in the context of grouping Dependabot security updates, where you will be able to say something like "for npm, group my security updates into 1 PR for all my npm directories in this repo." This is going to set up a path for us to later be able to target directories for any Dependabot configuration option, so that you can be as specific or as broad as you'd like when it comes to telling Dependabot how to update your dependencies.

I just can't give you a timeline on this work at this time.

It's been a while since this update, do you have any update @carogalvin?

[carlincherry]

👋 new Dependabot PM enters the chat -- I work closely with @carogalvin!

This feature is not on our roadmap, but grouped of security updates that Caro referenced has shipped, as well as multi-directory keys for the dependabot.yml and glob support. Used in conjunction give a decent way to bypass manifests in specific subdirectories (by grouping and globbing to the next-lowest directory using the directories key, then getting all the other ones you want using directory, a kind-of logical elimination of the manifest in the specific subdirectory you want to ignore). It's not perfect, and still leads to some duplicated config blocks, but hopefully helps.

I don't have a timeline on ignore conditions right now.

[bmiselis]

This definitely should be implemented! So helpful for monorepos 😭

[cbeauchesne]

It will be also useful for regular repo where the aim is to tests integrations with older components' versions. On those repos, some manifests must be updated, where other must not.

[cmeyertons]

@carlincherry does the dependabot globbing algo natively support excludes? I know some glob implementations do: https://www.baeldung.com/linux/globbing-exclude-pattern#using-negation-operators

[carlincherry]

@cmeyertons unfortunately not - the Dependabot globbing algo doesn't natively support excludes 😿

[cmeyertons]

@carlincherry gosh seems like a super small non breaking enhancement with minimal additional overhead to finally close out this issue…..

would be a nice feather in a cap for a new Dependabot PM 😄

[marcrohlfs]

Glob excludes wouldn't fix this for us. I did some tests with the directories glob patterns and noticed that they lead to separate change contexts for each effective pattern match. There are cases where we have the same (Maven) dependency versions configured in multiple subfolders of the project. Using the directory configuration, we get one pull request that contains all updates for the same dependency. When I tested the directories configuration with glob patterns, I got a separate pull request for each matched subfolder pattern. That would really complicate things for us.

[jameswilliamknight]

good guy dependabot making sure we move our experiments and PoCs (frozen as documentation) away from our production code... /s

I suppose it's tidier, but dependabot... don't touch my garbage!!!

[SeanFeldman]

It is not a mono repo but quite a large one, where Dependabot is timing out on a single project. I don't want to remove Dependabot, but being stuck on that single project creates a different .sln file (for NuGet packages), which is a nasty workaround, or it doesn't run Dependabot. If there was a way to exclude a folder, this would be a no brainer.