feat: Github fallback for empty PURL for license exclusion

[jscaltreto]

The action uses the change's package_url (as returned from the dependency graph API) to match against the exclusions passed via allow-dependencies-licenses. However, some changes do not include package_url, but they can still result in the action failing a license check as the check itself doesn't rely on package_url. Currently there's no mechanism in place to exclude a dependency from the license check if the package_url is empty.

This adds a fallback mechanism that parses source_repository_url to attempt to match based on the repository name. So allow-dependencies-licenses could include, for example, pkg:github/owner/repo and that would match a change with source_repository_url: "https://github.com/owner/repo".

This doesn't cover all cases; if source_repository_url is empty or doesn't point to a github-hosted repository then it will still fail to match.

[hmaurer]

Hi @jscaltreto , thanks for filing a pull request, and my apologies for the delay in reviewing it. Could you provide an example of a situation where package_url is not included but source_repository_url is? I know this would be the case for dependency changes to version ranges (e.g. to a package.json file). Is that what you encountered?

[jscaltreto]

Hi @hmaurer! The example where I encountered this was when using a package directly from a github repo instead of npm as one might do to install an unreleased version of a dependency. Here's a trivial example. In this case, calling the dependency-graph API the result contains:

 {
    "change_type": "added",
    "manifest": "package.json",
    "ecosystem": "npm",
    "name": "octokit",
    "version": "github:octokit/octokit.js#4.0.2",
    "package_url": "",
    "license": null,
    "source_repository_url": "https://github.com/octokit/octokit.js",
    "scope": "runtime",
    "vulnerabilities": []
  }

[hmaurer]

@jscaltreto I see, thank you for the prompt reply. Let me talk to some people internally about this. I wonder if the right approach here would be for us to change the API so that we'd return a PURL without a version specifier in such cases, similar to what you're doing in this pull request, e.g.

 {
    "change_type": "added",
    "manifest": "package.json",
    "ecosystem": "npm",
    "name": "octokit",
    "version": "github:octokit/octokit.js#4.0.2",
+   "package_url": "pkg:npm/octokit",
    "license": null,
    "source_repository_url": "https://github.com/octokit/octokit.js",
    "scope": "runtime",
    "vulnerabilities": []
  }

Ideally we would include a version specifier but we may not be able to do this in the short term.