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

[simonschaufi]

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]

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]

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

[Century-ss]

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

fetch-metadata/src/dependabot/update_metadata.ts

Lines 58 to 82 in 325b863

	const bumpFragment = commitMessage.match(/^Bumps .* from (?<from>v?\d[^ ]*) to (?<to>v?\d[^ ]*)\.$/m)
	const updateFragment = commitMessage.match(/^Update .* requirement from \S*? ?(?<from>v?\d\S*) to \S*? ?(?<to>v?\d\S*)$/m)
	const yamlFragment = commitMessage.match(/^-{3}\n(?<dependencies>[\S|\s]*?)\n^\.{3}\n/m)
	const groupName = commitMessage.match(/dependency-group:\s(?<name>\S*)/m)
	const newMaintainer = !!body.match(/Maintainer changes/m)
	const lookupFn = lookup ?? (() => Promise.resolve({ alertState: '', ghsaId: '', cvss: 0 }))
	const scoreFn = getScore ?? (() => Promise.resolve(0))
	if (yamlFragment?.groups && branchName.startsWith('dependabot')) {
	const data = YAML.parse(yamlFragment.groups.dependencies)
	// Since we are on the `dependabot` branch (9 letters), the 10th letter in the branch name is the delimiter
	const delim = branchName[10]
	const chunks = branchName.split(delim)
	const prev = bumpFragment?.groups?.from ?? (updateFragment?.groups?.from ?? '')
	const next = bumpFragment?.groups?.to ?? (updateFragment?.groups?.to ?? '')
	const dependencyGroup = groupName?.groups?.name ?? ''
	if (data['updated-dependencies']) {
	const dirname = branchNameToDirectoryName(chunks, delim, data['updated-dependencies'])
	return await Promise.all(data['updated-dependencies'].map(async (dependency, index) => {
	const lastVersion = index === 0 ? prev : ''
	const nextVersion = index === 0 ? next : ''
	const updateType = dependency['update-type'] || calculateUpdateType(lastVersion, nextVersion)

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]

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

[Nishnha]

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

[jeffwidman]

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]

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.