Re: [openchain] [germany-wg] [openchain-automotive-work-group] OpenChain Webinar 3 - Today (Monday) at 9am Pacific

Jeremiah C. Foster

On Fri, 2020-05-15 at 09:15 +0000, Thomas Steenbergen wrote:

You suggested converting the approval process into an app. I
wondered whether there have been implementations of open-source
tooling that does this?
Below I wrote out an example workflow, it's not a single web app as
Adobe presented [1] as we always prefer to integrate into existing
company’s systems to lower the threshold to user adoption.
This is smart, adapting to existing customer tooling is a wise choice.
Also, if you need to create an "app" or a set of more unified
functionality, creating a container that can access other tools with a
web UI has been a powerful approach in my experience.

| -> compliance rule engine
I've done something like this ---> | -> fossology
| -> web ui
| -> security tool
| -> . . .

This way you can also add a data base and use kubernetes on the control
plane allow for scale. Since the tools are containerized you can offer
the "app" as SaaS or on premise.

This at a high-level is how we have automated parts of our OSS policy
within our company using mostly open source tools.

== Example contribution approval app / workflow ==

For this example let's assume your contribution policy is based on
Google’s Open Source patching [2] and you have stack consisting out
of AWS lambda, Jenkins (MIT)[3] , JIRA, and OSS Review Toolkit
(Apache-2.0) [4] and ScanCode (Apache-2.0) [5]. A simplified version
of the approval app's workflow would then look something like:
IMHO I think one should use generic tools here, i.e. "Issue tracker"
instead of JIRA simply because not everyone uses JIRA and it may have
some special functionality you use that you assume exists in other
places. Have generic names means that tools can be interchanged in the
workflow and your more likely to have standardized interfaces (or
better, reuse existing standardized interfaces.)

1) User creates a JIRA ticket with the following fields:
- Title: what the contribution is about in a few sentences
- Description: describes in a few sentences the contribution
- VCS URL: URL to clone the repository to which they want to
We've been working on this internally (as have probably every fortune
500 company) and I've found to be
a very useful tool. Since this is W3C standardized data it will likely
easily fit in to tools and processes that are already existing.

2) User transitions the ticket from "open" to "scan" state.
3) Upon transition to the "scan" state JIRA calls an AWS lambda via a
REST call.

4) The AWS lambda verifies all required data has been provided.
If OK:
=> Calls Jenkins job via a REST call that will execute a scan with
OSS Review Toolkit of the master branch of repository specified in
=> The AWS lambda using JIRA's REST API adds a comment to the ticket
with a message which data need to be provided by the user and moves
ticket back to the "open" state.
5) In the Jenkins job OSS Review Toolkit using ScanCode scans the
source code and its dependency and then the scan results are
evaluated against a user-defined policy.
OSS Review Toolkit has Evaluator component that allows you to turn
Google’s Open Source patching rules like "No review required" and
"Forbidden patches" into OK / NOT OK checks.
It also support recording <package> or <package, version> approvals.
6) Once the OSS Review Toolkit scan completes Jenkins calls AWS
lambda with a link to the Jenkins job
7) AWS lambda fetches results from Jenkins job, processes the results
and using JIRA REST API updates the JIRA ticket.
If OK:
=> Updates ticket with a comment that contribution is OK with policy
and moves ticket back to the "completed" state.
If approval is required:
=> Updates ticket with a comment that contribution requires approval
and moves ticket back to the "needs approval" state and assigns it to
person who can do the approval.
=> Updates ticket with a comment why the contribution is NOT OK and
moves ticket back to the "denied" state.

If enough people are interested in this I can add Google’s Open
Source patching as one of OSS Review Toolkit's examples and explain
how it works in a future OpenChain call.
This is awesome, thanks for this! From my perspecitve we use a lot of
Free Software and our goal is to not just ensure that there is FOSS
compliance but that the customer's business model is effectively
aligned with copyleft and it's ethics. We've found a great deal of
interest in this combination and as such I'd be more interested in
either a contrast your proprietary approach or a version of your
workflow that was idempotent but used only FOSS tooling.




Thomas Steenbergen
Head of Open Source, HERE Technologies


On 15.05.20, 08:51, "germany-wg@... on behalf
of Shane Coughlan via" <
germany-wg@... on behalf of> wrote:

LEARN FAST: This email originated outside of HERE.
Please do not click on links or open attachments unless you
recognize the sender and know the content is safe. Thank you.

Let’s do the call. Perhaps next week? Then we can include it in a
forthcoming webinar before/after the main speakers.

> On May 14, 2020, at 0:38, Tobie Langel <@tobie>
> That's a great question for a topic I care a lot about. Happy
to dig deeper in a follow-up call or a pre-recorded video, as you
> Let me know how you want to proceed.
> Thanks,
> --tobie
> On Tue, May 12, 2020 at 9:22 AM Shane Coughlan <
@shanecoughlan> wrote:
> Steve, thank you for this question!
> Tobie, can we record the answer and include it in a forthcoming
OpenChain webinar? I’m thinking we hop onto Zoom for 5~10 minutes and
cover this.
> Shane
> > On May 5, 2020, at 19:36, Steve Kilbane <
@steve.kilbane> wrote:
> >
> > My thanks to all the presenters for the informative talks
yesterday. I very much enjoyed them.
> >
> > A follow-up question for Tobie, which I didn't raise at the
time due to a combination of a tight schedule and an over-abundance
of mute buttons...
> >
> > You suggested converting the approval process into an app. I
wondered whether there have been implementations of open-source
tooling that does this? It's obviously reminiscent of CLA/DCO
approval within GitHub, but I imagine that something different would
be needed, since this would be approval from the other side of the
contribution transaction.
> >
> > Thanks again,
> >
> > steve
> >
> >
> >
> >


This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

Join to automatically receive all group messages.