Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependency ecosystems not correctly detected #29

Open
martincostello opened this issue Jan 27, 2024 · 4 comments
Open

Dependency ecosystems not correctly detected #29

martincostello opened this issue Jan 27, 2024 · 4 comments
Labels
bug Something isn't working keep do not mark as stale ready-for-work Issue is defined enough to begin implementation

Comments

@martincostello
Copy link
Contributor

The logic to detect whether to configure package updates for most ecosystems, except for GitHub Actions and Terraform only appears to consider files in the root of the repository.

I found this after testing the action out on a .NET repository where the .csproj files are in subdirectories within the repository. The action generated a dependabot.yml file that only specified GitHub Actions updates.

Each file tested for should recurse through the repository to try and files (maybe within a configurable depth limit to reduce impact on rate limits) so that the generated file is a more accurate reflection of what should be configured.

@zkoppert zkoppert added bug Something isn't working ready-for-work Issue is defined enough to begin implementation labels Jan 29, 2024
Copy link

This issue is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Mar 13, 2024
@zkoppert zkoppert added keep do not mark as stale and removed Stale labels Mar 14, 2024
@zkoppert
Copy link
Member

For this maybe its better to temporarily clone the repository and do file search for project files? I feel like rate limits would be spent quickly otherwise.

@ricardojdsilva87
Copy link
Contributor

Hello everyone,
I was thinking of suggesting if it would make sense to add the option to be recursive on the scan?
For example on the terraform option, the files usually are located inside folders so the automation usually does not detect them.
I was thinking on a structure of doing a recursive search inside all folders and then use those folders where the files are found to be added to the settings of the created dependabot.yml file on the directory: key

The suggestion of cloning the repository would be a good option we could use any search option, for example I'm using the git ls-files on other project and it works fine, there would be the need to just parse the result and add the needed directories to the dependabot.yml configuration.

Would it make sense to do this for all the languages supported or for certain ones for now?

Thanks

@ricardojdsilva87
Copy link
Contributor

Hello, just noticed that on the dependabot configuration there is the option directories that can be used together with an wildcard:
https://docs.github.com/en/[email protected]/code-security/dependabot/working-with-dependabot/dependabot-options-reference#directories-or-directory--

This can be used also on GHE starting on version 3.14, before that only 1 folder can be used or by copying the block of configurations over and over again, just mentioning 1 folder at the time.

For some languages maybe we can search for what languages might be present on the repository itself? (this information)

Image

In this case we wouldn't need to search for the files and would just need to create an entry for Python and terraform and indicate that the directories are "/*", this would allow dependabot to search recursively on all folders on the repo and search for the updates.

I can try and revisit this later when we start to implement the changes.
Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working keep do not mark as stale ready-for-work Issue is defined enough to begin implementation
Projects
None yet
Development

No branches or pull requests

3 participants