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

[omnipitous]

In our case, which from previous comments seems somewhat typical, we can't skip the root of the repo as that is the root of the project and the Maven hierarchy descends from there so sounds like "directory:" wouldn't work unless we were able to use a "directory:" section to *exclude. We have a few subfolders that we do not want scanned and a BIG pile that we do so from a practical standpoint "excluding" is preferable to "including" as it requires less upkeep / initial create noise SO: a .dependabot-ignore file or a similar "in-config" ability to ignore specific subfolders would be preferable to having to get super explicit about what subfolders we "include".

[emihaase]

Finding this issue, I, too, would love this functionality, and have been searching for a way to implement it. Bump for visibility, in hopes it will be picked up.

[frederikheld]

I coming back to this after some time and see a lot of people rooting for a .dependabotignore file. Is there any argument for this solution except for "I'm not allowed to touch the dependabot.yml myself because someone else owns it and I don't want to talk to that person"?

I myself would prefer to have this as a feature in the dependabot.yml because my repo is already cluttered with too many .*ignore files. Also, if I move away from Dependabot, I don't want to remove all the .dependabotignore files all across my repo.

I don't mind to have the .dependabotignore file as an additional option, as there definitely is an use case for this, but IMHO this should not be the main option.

[ghjm]

I don't care how it's done, I just want to be able to recursively scan the root folder while ignoring particular subfolders. Perhaps the argument for .dependabotignore is just that it's a familiar pattern and you don't have to learn a new syntax to use it.

[jeffwidman]

Related:

• https://github.com/dependabot/dependabot-core/issues/2883

[soywiz]

In my case I have a Kotlin Multiplatform project with Gradle with versions defined in gradle/libs.versions.toml. And dependabot is tracking all build.gradle, settings.gradle and doing crazy things like: https://github.com/korlibs/korge/pull/1428/files it also explores yarn.lock. I want dependabot to only track gradle/libs.versions.toml and ignore everything else.

[yeikel]

In my case I have a Kotlin Multiplatform project with Gradle with versions defined in gradle/libs.versions.toml. And dependabot is tracking all build.gradle, settings.gradle and doing crazy things like: https://github.com/korlibs/korge/pull/1428/files it also explores yarn.lock. I want dependabot to only track gradle/libs.versions.toml and ignore everything else.

The example you listed looks like a bug and should be filled separately.

[LofiBeatsToCodeSlashChillTo]

Not to beat this dead horse like rocky, but for the love of all that is good. This is basically causing an issue in my org where dependabot can't be used correctly due to it's interaction with serverless/deployment scripts for serverless.

[nicojs]

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

I remembered I did that back in the day. No luck.

[samsmithnz]

+1. I have a dev tool that I use to scan older projects and Dependabot generates a load of updates I would prefer to suppress.

[socketbox]

This is also problematic in the case of git subtrees. We have a repo that is used as a subtree in many projects. If we enable dependabot in those dependent/client projects, it flags dependencies that belong to the subtree in each project.

[lmrb-1968]

+1. We have many unit tests with "vulnerable" versions in manifests, precisely for a security tool ! It is annoying that we have to manually check and skip manually the security alerts and PRs...

[leoperria]

+1

[mervyn-mccreight]

+1 for this.

I encountered this when using dependabot for Gradle projects that use Composed Builds, enabling dependabot for one specific project triggers dependabot to also check all included builds and opens PRs updates, but names the PR as it was part of the one specific project.

/edit: This seems to be the expected behaviour (https://github.com/dependabot/dependabot-core/commit/0cdebde199ca930a2367747fead799a76e38b5a6) which makes sense in general, but when you have multiple projects using the same included build in one repository (like in a mono-repo setup), every project will scan the shared include builds for updates and open separate PRs for them.

For me it would be more ideal to explicitly add the projects that are getting included to tell dependabot to scan for them. But I can't, since I'm not able to tell dependabot to ignore the included build files.

[adrianhallnhsd]

+1

[saulotoledo]

+1 Use case: a submodule in a monorepo needs a lock in a specific version for a dependency and should not be updated. The remainder of the mnonorepo should receive updates as usual. We should be able to ignore that specific dependency for a specific folder.

[1uss1]

+1

[hildebro]

+1

[viceice]

+1

please avoid such comment, too much noise for nothing. use the thumbs up Emoji on issue

[cdmistman]

+1 my use case: working on a tool that composes package managers, as such i have a directory with a bunch of templates that contain spec/lock files (eg package.json and package-lock.json) that don't need updates, and the dependabot PRs are too noisy