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.

[thibaultcha]

Use case: I have a monorepo with several projects & ecosystems (cargo and github-actions). Some cargo crates are shipped artifacts while others crates are only used in the monorepo's test suite. Both types of crates have entirely different dependencies.

In this scenario:

1. I want to enable monthly version bumps in all of the monorepo's crates.
2. But, I only want to enable security bumps in the crates that are actually shipped to end users. I don't want the noise of monitoring the test crates security bumps, they can wait for the group's monthly bump PR.

I would love to see this because it could greatly reduce the dependabot PR noise to a few PRs that really matter: important security bumps, and regular version bumps.

Thanks for your consideration, cheers.

[AyanSinhaMahapatra]

+1 to this issue. I have a similar use case to @jirikrepl and would love to see this feature implemented.

I help maintain https://github.com/nexB/scancode-toolkit and this is a code scanner for package/dependency information, and as a result we have lots of older package manifests as test files in our tests directory (see https://github.com/nexB/scancode-toolkit/tree/develop/tests/packagedcode/data for example), which generates a lot of false positives in dependabot notifications, for vulnerable packages, when these are not at all dependencies. This would be the case for any code-scanner/dependency too which has package manifests which are not really used to build the project.

It would be great if there was some global ignore_directories list of paths (or even globs if you want to be fancy) present in the dependabot.yml, which dependabot will ignore when looking for package manifests, and hence will reduce the usual noise of notifications which I'm drowned by usually (and other people here with examples like monorepos).

The ignore option provided today at https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore is of course inadequate, as all the dependencies by ecosystem, with names and versions have to be specified, which requires a lot of work honestly to maintain, and also the option to provide the directory the manifests are present at: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#directory but a common case is manifests are present at root and some directories need to be ignored. There could also be a value under this option to ignore specific sub-directories from the root.

[neverbot]

This issue seems to have the attention of a lot of people, but it is yet untriaged, so it's not in the planning, I think. Does anybody knows who could be contacted to know something more about its current status?

Maybe @jakecoffman or @brrygrdn?

[carogalvin]

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

[davidwartell]

+1 I have over 3,000 enterprise repos for NYSE company and many false positives. For example in one repo I have nodejs package.json for node packages used to generate API docs and the vulnerabilities in code used for code generation are noisy false positives. Being unable to exclude files/dirs makes dependabot almost useless at this scale.

[omnipitous]

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

This particular feature is not currently scheduled on our roadmap.

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.

Welcome to the thread! Glad to hear it's at least not been lost. The above sounds like a nice add to the system and the promise of a more robust way to more granularly configure the processing off in the future is at least a ray of hope.

That being said: This's a far more complicated solve than this more than 2yo highly-desired thread is looking for and from your verbiage sounds like it'll be a long while before we see any payoff. The previously mentioned .dpignore pattern (either at the root or more of a robots.txt style drop the file in folders you want excluded) is a very old and well tread pattern that is nearly trivial to implement in a directory crawler's code and would provide much faster benefit to this community at a severely lower implementation cost to the Dependabot developers.. could its absence from the roadmap be reconsidered?

Thanks

[joakime]

Looking forward to the future solution.

Unfortunately .dpignore is a partial-solution for a narrowly defined problem set on this issue. We don't want a wholesale ignore of a directory, but have different configurations for different lists of directories.

Example:

• Config A - mainline code tree : almost default configuration
• Config B - environment 1 tree : specific ignored dep version ranges
• Config C - environment 2 tree : different specific ignored dep version ranges
• Config D - integrations : major dep version updates ignored (only minor and security updates)
• Config E - test code : only update testing code / bootstrap, never any of the integration configurations

[adrianhallnhsd]

@joakime I'd argue that a .dpignore is exactly a solution to this issue:

"Ignore manifests in specific subdirectories"

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

If you have a different set of requirements, then shouldn't these be in a separate but linked issue?

[GriceTurrble]

Kind of a similar issue to this. Dependabot's being a bit too greedy looking for manifests.

I have a monorepo for my Advent of Code solutions, and I just set it up to check the dependencies for the past years (which use Poetry pyproject.toml files) with separate D-bot configs in order to group them.

However, D-bot is looking recursively through my input.txt files, reading small strings like 1777 and 2345 as if those might be packages, and slamming PyPI with searches for all of them. In fact the whole D-bot job times out and fails to generate any PRs.

I really just want it watching the contents of the exact directory I told it to watch. If I want it to work recursively, perhaps it can permit a glob pattern in directory? Or set a boolean recursive?

[BT-rmartin]

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

@carogalvin Any news on this?

[carogalvin]

@BT-rmartin nope, I will post here when this changes 👍

[justinmchase]

I don't think I really care if its one entry with multiple directories or multiple entries with one directory so long as the final product produces one pull request with all of the updates.

I see there is a "group" feature in the documentation, can we not extend groups to apply across entries such that if they land in the same group they will end up being in the same pull request?

[Dreamsorcerer]

I don't think I really care if its one entry with multiple directories or multiple entries with one directory so long as the final product produces one pull request with all of the updates.

Are you commenting in the right issue? This is about ignoring directories, so expected result is that should no pull requests updating those directories.

[slaFFik]

It looks like I was able to achieve this using this example config added to the devendabot.yml file:

  - package-ecosystem: "npm"
    directory: "/directory-to-exclude"
    schedule:
      interval: "monthly"
    labels: [ ]
    ignore:
      - dependency-name: "*"

Note the ignore part.

I got the idea from the docs: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore and this sentence:

You can combine this with dependency-name: "*" to ignore particular update-types for all dependencies.

After pushing it, dependabot PRs to the excluded directory were auto-closed.

[adrianhallnhsd]

It looks like I was able to achieve this using this example config added to the devendabot.yml file:

  - package-ecosystem: "npm"
    directory: "/directory-to-exclude"
    schedule:
      interval: "monthly"
    labels: [ ]
    ignore:
      - dependency-name: "*"

Note the ignore part.

I got the idea from the docs: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore and this sentence:

You can combine this with dependency-name: "*" to ignore particular update-types for all dependencies.

After pushing it, dependabot PRs to the excluded directory were auto-closed.

To be clear about your workaround, this doesn't actually exclude the directories from scanning , right? It just auto-closes teh PRs.

This feature request is specifically about ignoring subdirectories completely

[slaFFik]

@adrianhallnhsd Yes, you are correct. From user point of view that's the same (no action). From Dependabot PoV - it just did a useless job.

Ideally yes, there should not be check at all.

[adrianhallnhsd]

@adrianhallnhsd Yes, you are correct. From user point of view that's the same (no action). From Dependabot PoV - it just did a useless job.

Ideally yes, there should not be check at all.

Those dependency alerts will still have fired, and the list will still be present though, right? Just because the PR was raised then closed doesn't make the alerts and big list go away. If it does, happy to be corrected.

[carogalvin]

@adrianhallnhsd if you're looking to reduce the number of Dependabot alerts and not just PRs, have you looked at our auto-triage rules engine? This can be used in public & GitHub Advanced Security-enabled repos to set rules to automatically dismiss alerts that meet certain criteria.

[WillBeebe]

sad :/

[johan-ripoll]

Seems like a lot of people are waiting for this very (basic) functionality.

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