dependabot / fetch-metadata

Extract information about the dependencies being updated by a Dependabot-generated PR.
MIT License
170 stars 61 forks source link

Dependabot "update-type" not available in metadata retrieved for PR #499

Open simonschaufi opened 6 months ago

simonschaufi commented 6 months ago

Hello, I have the same issue like this person: Dependabot "update-type" not available in metadata retrieved for PR using dependabot/fetch-metadata@v1

For example here: https://github.com/simonschaufi/php-libkml/actions/runs/8285139412/job/22672206081

Run dependabot/fetch-metadata@v1.6.0
  with:
    github-token: ***
    skip-commit-verification: false
    skip-verification: false
Parsing Dependabot metadata
Outputting metadata for 1 updated dependency
  outputs.dependency-names: rector/rector
  outputs.dependency-type: direct:development
  outputs.update-type: null
  outputs.directory: /
  outputs.package-ecosystem: composer
  outputs.target-branch: main
  outputs.previous-version: 
  outputs.new-version: 
  outputs.compatibility-score: 0
  outputs.maintainer-changes: false
  outputs.dependency-group: 
  outputs.alert-state: 
  outputs.ghsa-id: 
  outputs.cvss: 0

As you can see, outputs.update-type is always null

This is my workflow: https://github.com/simonschaufi/php-libkml/blob/main/.github/workflows/dependabot-auto-merge.yml

Is there some misconfiguration or is this really a bug?

simonschaufi commented 6 months ago

Similar but not the same: #339. On that bug report it's about the v prefix but in my case there is a simple version bump without the v prefix.

simonschaufi commented 4 months ago

@Nishnha could you give me some information about this issue?

Century-ss commented 3 months ago

@simonschaufi It seems that update-type is generated from the version information in the commit message as shown below. However, there are cases where the version information is not included in the commit message, in which case update-type becomes null.

https://github.com/dependabot/fetch-metadata/blob/325b863556700e5e4d4ec23381993ef460dd8379/src/dependabot/update_metadata.ts#L58-L82

In the above example, the commit message was as follows.

Updates the requirements on [rector/rector](https://github.com/rectorphp/rector) to permit the latest version.
- [Release notes](https://github.com/rectorphp/rector/releases)
- [Commits](rectorphp/rector@1.0.2...1.0.3)

---
updated-dependencies:
- dependency-name: rector/rector
  dependency-type: direct:development
...

Signed-off-by: dependabot[bot] <support@github.com>

There are two possible solutions. 1, Get the version information from somewhere other than the commit message (such as the title of the PR). 2, Modify the commit message so that the version information is always included (probably needs to be modified in other repositories).

@Nishnha I could not decide which option is better and would appreciate your opinion. This also occurs in the latest v2 as well as v1.

simonschaufi commented 2 months ago

I think option 1 is the easier and better solution here.

Nishnha commented 2 months ago

Hi are these PRs that address a security update? We don't include the update-type for security updates at the moment.

jeffwidman commented 2 months ago

To add more context, so far we've purposefully avoided exposing update-type as we don't want to advertise that the repo getting the PR might have an open vulnerability.

I realize security by obscurity isn't great, and technically someone could figure this out themselves by cross-referencing CVE data with library versions... but still, let's not make the bad guys job easier.

One idea we've considered is that the risk is much lower for innersource/private repos, so we could optionally expose it for them. But suddenly this gets a bit more complicated and requiring more engineering time and so far it's not that frequently requested by users. So I don't expect us to actually spend any time on this anytime soon.

timbru31 commented 1 week ago

Hi are these PRs that address a security update? We don't include the update-type for security updates at the moment.

Nope. We are seeing it for regular dependency updates, too. Interestingly only for those who Updates the requirements on X to permit the latest version. and not the Bumps x from y to z.

Screenshot 2024-09-02 at 12 35 33