dependabot / fetch-metadata

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

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

Open navruzm opened 7 months ago

navruzm commented 7 months ago

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 commented 7 months ago

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.