[ci] run dash-licenses as part of GH workflow

[marcdumais-work]

What it does

Add a "3PP FOSS license check" GitHub workflow, that uses
the Eclipse Foundation's dash-licences tool to validate the
licenses of our npm dependencies.

One can also run the license check locally with command:
"yarn license:check"

I have considered 3 alternatives:

(1) add the license check as a step of the build job of the build workflow.

The license check step needs to report
success or it will fail the build job and the publish job
(when it applies). If the license check reports success, it's
burried in the multiple steps of its job, not discoverable
from the PR page.

(2) add the license check as a new job in the build workflow.

This works better but there is redundency in the job - we need
to re-install node, checkout the repo, etc.

One advantage of this approach is that the license check has
visibility in the PR's CI checks section and can be made to fail
without impacting the other jobs.

(3) (chosen) add a new workflow for the license check

Like option 2, this gives the license check visibility
in the PR's CI checks section and the job can fail without impacting
other workflows/jobs.

This option has the additional advantage that it's quite
generic (npm/yarn projects) and could be re-used more
easily, without changing the main workflow of the adopting repo.

How to test

• Run the license check locally:
  yarn license:check and verify that ~38 dependencies are found that need attention
• Look at this PR's CI steps and verify that 3PP License Check fails, and in the log, lists the same dependencies

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[paul-marechal]

Mostly LGTM, just pushed a commit to improve the script a bit.

[paul-marechal]

Also how do we deal with the failing CI?

[marcdumais-work]

Also how do we deal with the failing CI?

For now this is just informational. It's expected that the license check job will be shown as failed all the time. PRs that introduce new dependencies should still check them as per our process. In parallel, the dependencies that routinely fail the check are being investigated, and their number will slowly go down, eventually to zero (in theory).

As a follow-up, we could add a white-list of dependencies that are know to be ok for our project (or at least being investigated), that would be filtered-out.

[paul-marechal]

As a follow-up, we could add a white-list of dependencies that are know to be ok for our project (or at least being investigated), that would be filtered-out.

I can see to implement this, because I am not fond of having a failed check on each and every PR from now on :)

[marcdumais-work]

I can see to implement this, because I am not fond of having a failed check on each and every PR from now on :)

It does reflect reality though - not all that's listed is approved or being investigated ATM.

[paul-marechal]

Agreed, but I think "unknown" status is different from flat out "dependency license is problematic" hence why I would only expect to fail because of the latter.

[waynebeaton]

LGTM

[paul-marechal]

\o/ Woohoo the 3PP check is green!

I added a commit that implements a baseline: Even if dash-licenses fails, if what is reported is part of the baseline then we'll ignore its error code and exit normally.

The baseline is currently a map of entries (as reported by dash-licenses) to an optional data. My idea is to map each entry to its associated CQ (approved or not) to help keep track of what's what, as I currently have no idea if anything is already cleared.

@marcdumais-work I invite you to fill the baseline with URLs to relevant CQs for what you know about. This should help with understanding what's the state of each dependency defined in this baseline.

In the future as those dependencies get cleared or not, we shall remove entries from that baseline until it is emptied?

[paul-marechal]

Note that I also tried to update the documentation about PR handling regarding this new check.

[marcdumais-work]

In the future as those dependencies get cleared or not, we shall remove entries from that baseline until it is emptied?

yes, we can do that. I submitted a CQ recently that should clear all our production dependencies, so for the most part, the baseline is composed of lower-priority test/build dependencies.

[paul-marechal]

I know it's mostly my code now, but LGTM!

[marcdumais-work]

In the future as those dependencies get cleared

One bonus feature could be to list those baseline dependencies that have not come-up in the current scan. It probably means they can be removed, e.g. when we next modify that file.

[paul-marechal]

@marcdumais-work done.

Apparently there were updates as entries that I had to include in the baseline yesterday seem to not be reported today:

edit: I also notice that GitHub action just got mixed up when printing stdout and stderr...

---

It should look like this:

Weird quirk, but fine to me for now.

[paul-marechal]

Will merge after the 1.17.0 release.

[marcdumais-work]

Apparently there were updates as entries that I had to include in the baseline yesterday seem to not be reported today:

I manually ran the license-check in the "auto-submit" mode, which knocked-off a few dependencies. I'll do that once in a while.