Automate filing third-party content review requests #51
Comments
I have good news. I've actually already committed the code that does this (0ffba5e). It doesn't actually create a CQ; rather, it creates a GitLab Issue (e.g.). I haven't yet written down how to actually use the feature yet, primarily because I'm not quite ready yet for the deluge of requests that might come (we haven't written the backend code yet, so processing these is entirely manual). It's still all very experimental, so there will be changes. But it should get the job done for your immediate need. Short version:
Please do not run this if you have more than dozen or so dependencies identified as requiring review. At least not yet. |
|
Great! Then I suggest it's mostly a matter of adding such info in the standard output to make it more accessible. I'll make a PR that copies your comment here. |
|
Submitted #53 to help people leveraging this great capability. |
Actually... it's mostly a matter of finding cycles to put some automation support on the backend before somebody runs it on their list of 4,000 NPM dependencies. At this point, my primary interest is whether or not this actually works for you. There are no new issues in the GitLab repository. Did you try it? I haven't fully tested the privileges on the repository. Ideally the ability to create issues should be available (and limited) to all committers. |
|
I already opened the CQ yesterday, so I didn't use it. |
|
Try it anyway. It would be helpful. |
|
This works like a charm! |
|
I'm going to leave this issue open to provide a place to discuss this functionality while we evolve the implementation. |
|
Note that I've added some code in place to throttle creation to five requests. My intention is to open this up, but only after we have some proper automation supporting the backend. |
waynebeaton
changed the title
hehe :)
Please ping me when you think this is ready for use in a "friendly" project's CI. In the meantime I'll consider adding it as an information step, that scans and informs about suspicious dependencies, but does not automatically submits them for review. |
Don't laugh too hard; I was thinking of you when I typed that. :-) |
|
As an experiment I did a run, using Theia's This new run seem to mis-parse packages that start with a
Full results: License information could not be automatically verified for the following content: npm/npmjs/-/ajv/6.12.6 This content is either not correctly mapped by the system, or requires review. Setting up a review for npm/npmjs/babel/helper-hoist-variables/7.14.5.
More content needs to be reviewed. |
It's been a while since I wrote that code, but I swear that I observed the ClearlyDefined ids omitted the '@'... Regardless, that does not appear to be the case. I'll fix it (and the issues that were created). Thanks for point this out. |
|
I've pushed an update and have kicked off a build. The update should be reflected in repo.eclipse.org in a few minutes. |
|
Awesome! I'll try this offline first |
Confirmed. I now obtain exactly the same "unverified dependencies" list locally, using |
|
This is alive and working. |
I happily run dash-license tool and get a clear and useful output
Now, I'd like the extra step forward, just like pushing on GitHub suggests a link to directly create a pull request: a prepopulated link to open a CQ for those
The text was updated successfully, but these errors were encountered: