`fetch-metadata` action returns `/` for directory output

[navruzm]

I am using the dependabot/fetch-metadata action (latest version) in my workflow to handle Dependabot pull requests. However, I am encountering an issue where the directory output is returning / for all directories.

PS: I'm using Dependabot with the group feature.

Here's the dependabot.yml configuration for the repository:

version: 2
updates:
  - package-ecosystem: "gomod"
    directory: "/v1/"
    schedule:
      interval: "daily"
    groups:
      all:
        patterns:
        - "*"

  - package-ecosystem: "gomod"
    directory: "/v2/"
    schedule:
      interval: "daily"
    groups:
      all:
        patterns:
        - "*"

Here's an example of the outputs returned by the dependabot/fetch-metadata action:

Run dependabot/fetch-metadata@v1
  with:
    github-token: ***
    skip-commit-verification: false
    skip-verification: false
Parsing Dependabot metadata
Outputting metadata for 4 updated dependencies
  outputs.dependency-names: github.com/fatih/color, github.com/fatih/structtag, github.com/spf13/cobra, github.com/spf13/viper
  outputs.dependency-type: direct:production
  outputs.update-type: version-update:semver-major
  outputs.directory: /
  outputs.package-ecosystem: go_modules
  outputs.target-branch: main
  outputs.previous-version: 
  outputs.new-version: 
  outputs.compatibility-score: 0
  outputs.maintainer-changes: false
  outputs.dependency-group: all
  outputs.alert-state: 
  outputs.ghsa-id: 
  outputs.cvss: 0

Here is the example PR link: https://github.com/navruzm/depbot/pull/1

[dreid]

This issue is caused by https://github.com/dependabot/fetch-metadata/blob/main/src/dependabot/update_metadata.ts#L52

That code is expecting the branch name to contain the dependency name when for grouped updates it will only contain the group name, and because all the dependency names contain multiple /s it is failing to get the directory name.

This is similar to #493 and #494, but it is not addressed by my pr #495.

[Nishnha]

Should be fixed by #565.

Thanks!