Add 'context' option for license-tool-plugin

[HannesWell]

If the license-tool-plugin would have some sort of 'context' field the automated license-vetting workflow could pass the URL to the GitHub comment that requested the license vetting and that URL could be included into the issue message at iplab.
This would allow to contact the requestor of the license vetting more easily in case there is demand for that.

[waynebeaton]

So... this would just be a URL (or some other arbitrary bit of information) that we'd just include in the issue. That seems relatively straightforward.

The other thing that we need is some means of adding committers in copy, when -- for example -- a bot is the one initiating the reviews. But I'll track that in a different issue.

[HannesWell]

So... this would just be a URL (or some other arbitrary bit of information) that we'd just include in the issue. That seems relatively straightforward.

Yes, exactly. In case of the license-vetting workflow I would use the mentioned URL, but in other cases something else might be useful, so using just an arbitrary String could be useful. And if it is presented as arbitrary context in the generated IPlab issue message it should still be understandable. I assume that is only used when there is some sort of problem, which is usually handled by a human so the context probably does not have to be machine-understandable.

The other thing that we need is some means of adding committers in copy, when -- for example -- a bot is the one initiating the reviews. But I'll track that in a different issue.

I thought about that as well in the past. And the GitHub API provides information about the user who created the review-request-comment. Since only the review requests from commiters are processed the issuing committer could be added to the request as well.
The biggest problem I see here is that, the GH API only provides the GH-user id. So we would need a mapping from GH-user -> EF-Gitlab/IPlab user. If that exists that should be straight forward as well.
But yes lets track that in another issue.

[waynebeaton]

There's APIs that can help with the mapping. But I get the sense that we're starting to talk about a very specific use case and I'm not sure how much I want to invest in very specific use cases. Still... let's explore it.

In the simplest case, we could add the ability to insert arbitrary text into the issue description. That text could include references to individuals who need to copied, links, or whatever else the committer thinks is useful to the project and IP teams...

[mickaelistria]

I opened #351 as a duplicate. This is IMO the very missing thing of IP workflow. Having proper links between PR and IP review would allow much more efficient workflow and notifications, bascally reducing a lot of custom scripts on project end, and allowing to implement bots that would prevent project maintainers from manually checking and remembering about a lot of things.

[waynebeaton]

There's a feature by which the tool will include a link to the Git repository from which the tool is invoked. It uses Eclipse JGit to automatically identify the remote repository based on the working directory. This information can also be provided manually via a -D parameter.

I'm wondering if we might be able to do something similar here. Is it possible to determine the PR entirely from context? e.g., can we make a good guess at the PR from the branch?

[mickaelistria]

There is no 1-1 mapping between a commit, a branch or a PR. A same commit can appear in multiple branches, and in different PRs, the same branch can even be used to create multiple PRs, sometimes against different repos...
Trying to infer a PR from a Git repo state seems rather hard and unreliable in general, I'm not convinced it's the best apprach.

GitHub actions have github.event.issue.pull_request variable available that's easy enough to pass to the dash-icense-tool. I would recommend that we just let the dash-license-tool use it and that will be very sufficient with a possibly much faster time-to-market.

[HannesWell]

I'm wondering if we might be able to do something similar here. Is it possible to determine the PR entirely from context? e.g., can we make a good guess at the PR from the branch?

In a GitHub workflow the information for which PR the workflow is running is available (as Mickael said).
So if there where some context field that can contain any text e.g. added to the created issue the workflow could fill that text field with a link to the PR.
That would be simple to achieve.

Having proper links between PR and IP review would allow much more efficient workflow and notifications, bascally reducing a lot of custom scripts on project end, and allowing to implement bots that would prevent project maintainers from manually checking and remembering about a lot of things.

Having automated feedback, e.g. in form of a comment on the originating PR would be much more complicated since probably the Gitlab backend would have to call some GH webhooks to create the comment.
A solution in between could be that the requestor of the review is automatically subscribed to the Gitlab issues. In the workflow we know the GH id of the requestor, but I don't know if gitlab can then identify the corresponding Gitlab user (ids are probably different).