morningman opened a new pull request, #67396:
URL: https://github.com/apache/doris/pull/67396
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
`Dependency License Review` fails any pull request that adds a JUnit
dependency to a pom — in practice, any pull request that adds a Java module
with a test. It happened twice on 2026-09-01 alone, on two unrelated branches:
```
The following dependencies have incompatible licenses:
fe/be-java-extensions/hive-apache-shade/pom.xml » junit:junit@ – License:
EPL-1.0
fe/be-java-extensions/jni-spi/pom.xml » org.junit.jupiter:junit-jupiter@ –
License: LicenseRef-bad-non-standard
...
```
Neither failure is about a licence the project has not approved:
* **`org.junit.jupiter:junit-jupiter` is EPL-2.0**, which `allow-licenses`
already carries. GitHub's dependency graph reports its licence as
`LicenseRef-bad-non-standard`, so the check rejects a licence the project has
already accepted. This is a data-quality gap on GitHub's side, not a dependency
problem.
* **`junit:junit` is EPL-1.0**, an ASF Category B licence. It is test scope,
reached by the JUnit 4 tests that run through `junit-vintage-engine`, and no
release artifact ships it.
Both are excluded by purl — the same package-specific shape the existing
`caniuse-lite` exception uses — rather than by widening `allow-licenses` or by
dropping `development` from `fail-on-scopes`. `allow-dependencies-licenses`
excludes a package from the **licence check only**, so vulnerability reporting
for test-scope dependencies is unchanged.
One detail worth recording, since it is not in the action's README: the
action matches a purl on **type and name and ignores the version**
(`purlsMatch` in its `src/purl.ts`). So the version-less entries added here
cover every version, and the version pin on the existing `caniuse-lite` entry
has no effect either.
### Release note
None
### Check List (For Author)
- Test
- [x] Manual test (add detailed scripts or steps below)
Verified against the real payload rather than by inspection.
1. The dependency-graph compare API for one of the branches that hit this
returns, for these two coordinates:
```
name=junit:junit version='' scope=development
license='EPL-1.0'
package_url='pkg:maven/junit/junit'
name=org.junit.jupiter:junit-jupiter version='' scope=development
license='LicenseRef-bad-non-standard'
package_url='pkg:maven/org.junit.jupiter/junit-jupiter'
```
The `package_url` values are byte-identical to the entries added here,
and non-empty — which is what the action requires to exclude a change at all
(`groupChanges` skips the exclusion list when `change.package_url.length ===
0`).
2. Replaying the action's own filter (`purlsMatch` over type and name,
`fail-on-scopes`, `allow-licenses`) across all 223 changes in that payload
takes the result from the **nine incompatible licences the workflow actually
reported to zero**, with no other dependency newly excluded.
3. The three purls parse under `packageurl-js`, the library the action
validates them with, each yielding a `name` (its extra requirement); and the
folded YAML value parses to exactly those three comma-separated entries, which
`parseList` trims.
- Behavior changed:
- [x] No.
- Does this need documentation?
- [x] No.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
