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!

[alexweininger]

Would love to see this feature implemented! We have sample projects used for tests that we'd really love to be ignored by Dependabot.

[msxavi]

I can see that the owners a quite responsive and agile here. 😄 I'm just another person who needs this.

[balramkhichar]

Another person requesting for this. 😄

[AllanOricil]

Useful when working with monorepos

[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.

[dep]

+1. would also like this.

[batmac]

I would love this too!

[cmawhorter]

personally, i'd rather not have to update a dependabot.yml file to get this. i'd much prefer just throw an empty .dependabot_ignore file alongside the problem manifest or whatever. that'd also play nicer with template repos

[ilia-kebets-sonarsource]

We have a use case where we would like to ignore folders containing fixtures with lockfiles.

[Sajid78612]

This along with an option to ignore specific files would be very helpful.

[nicojs]

For anyone interested in this feature, your best shot is to bite the bullet and move to renovate bot: https://github.com/renovatebot/renovate

[vishiy]

+1

[deivid-rodriguez]

Hei, sorry for the lack of response here.

I think either an option to ignore directories or a .dependabotignore file could be possible options for this, but I also wonder whether there's something else going on here.

Is the directory: option currently recursive, and that's why this can't be workaround by explicitly defining the folders that you want watched? Does that depend on whether the directory option has the / value or something else, as suggested by https://github.com/dependabot/dependabot-core/issues/4364#issuecomment-1118256638? I think it's worth investigating these answers before anything else.

[douglasg14b]

Are there particular troubles with implementing a .dependabotignore file right away?

[joakime]

In our use case, we have a repo with support for 3 different major runtimes (java).

We can't use dependabot on it as it tries to keep all 3 directories aligned to the same versions (which doesn't work in java). So we want the ability to setup 4 different configurations in the dependabot.yml to specify ...

1. root & core updates (ignoring directories for runtimes)
2. updates for runtime 1 directory
3. updates for runtime 2 directory
4. updates for runtime 3 directory

A .dependabotignore file wouldn't help us (unless that name was configurable on a per-config basis?)

[deivid-rodriguez]

Are there particular troubles with implementing a .dependabotignore file right away?

Not particularly, we just want to be sure we have a proper understanding of what's needed before committing to adding any feature. And even if we decided to go with that, it may not be prioritized at all anyways.

We can't use dependabot on it as it tries to keep all 3 directories aligned to the same versions (which doesn't work in java). So we want the ability to setup 4 different configurations in the dependabot.yml to specify ...

And the directory: option does not work for you, right?

[joakime]

And the directory: option does not work for you, right?

The directory: without ignore is not useful on our maven projects. So for configuration 1 (root & core updates), the directory is /, so as to get the top level pom.xml and important core level projects. But we need to exclude / ignore directories like /runtime-1/* or /integration-tests/* (which contains validation of support for older library versions) from the dependabot execution on that config.

And then for configuration 2 we would have a directory /runtime-1 (ignoring root/core entirely, allowing a separate set of rules, tracking of dependencies for runtime-1, separate from the first config)

[deivid-rodriguez]

I see, so at least directory: works for /runtime-1 and siblings, but not for root updates, correct?

[joakime]

@deivid-rodriguez the directory: configuration works in many simple maven projects.

However, if our /runtime-1 has it's own /runtime-1/integration-test/ then the simple directory: configuration wouldn't work without the ability to specify what to skip.

Right now, many of our problematic dependencies (found in /integration-test/) are being skipped on a per-dependency basis with the ignore: -dependency-name / versions configuration, but that's insufficient for many of the dependencies, and that list is growing ever larger and getting harder to maintain, being able to skip by directory in these cases is viewed as very useful (for both the scope of dependabot updates and sanity of the developers)

[ghjm]

My situation is that I have a repo with a git submodule in it. I don't have control over what's in the other repo and there's no point having Dependabot scan it. But I can't use directory: because my own go.mod is in the root. Ignoring the directory via .dependabotignore would work fine for my use case. (Though it would be nice to still get update notifications on the submodule itself.)