ort
ort copied to clipboard
oss-review-toolkit
Create a GitHub Action to run ORT from PRs
By leveraging the Action Toolkit, we should create a GitHub Action to run ORT as part of PR checks.
Some related projects:
- https://github.com/boschcrank/ort-scan-test/blob/master/.github/workflows/build.yml
- https://github.com/philips-software/spdx-action
- https://github.com/alliander-opensource/license-scan-action
- https://github.com/mmurto/ort-demo/blob/master/.github/workflows/ort.yml
- https://github.com/splunk/addonfactory-ort-action
- https://github.com/edulix/ort-action
- https://github.com/itrich/ort-action
- https://github.com/tortellini-tools/action
Related project: https://github.com/philips-software/spdx-action
However, I believe a GitHub action should not create SPDX, but SARIF, and use the GitHub API to upload it.
@sschuberth I was confused by your comment on SARIF. I only knew of SPDX and never heard of SARIF. But if I understand you correctly, by adopting SARIF for GitHub Actions, GitHub will be able to interpret and represent the results? Similar to how GitLab can interpret the license scanning results as demonstrated in the linked video: https://www.youtube.com/watch?v=dNmH_kYJ34g Right? In that case I see the benefit for SARIF. Personally I'd still like SPDX for reference and archival, but SARIF will be more helpful for developers 'living' in GitHub :smile:
I only knew of SPDX and never heard of SARIF. But if I understand you correctly, by adopting SARIF for GitHub Actions, GitHub will be able to interpret and represent the results?
Correct. However, the way GitHub displays results from SARIF is by inline code comments. And it's a bit questionable to which line of your code e.g. a "problematic" license finding in a transitive dependency should be attached to. So there are still open "workflow" questions, and / or whether the SARIF output format it really suitable for the type of findings ORT provides.
From my initial setup at Alliander I started developing a more reusable action: https://github.com/alliander-opensource/license-scan-action At the moment I'm reworking it from a 'composite step' into a 'Docker compose step' which makes it easier to supply all sorts of environment variables: https://github.com/alliander-opensource/license-scan-action/pull/9
@tsteenbe suggested to create a separate git repository under the ORT organization as a home for an official ORT action. I'd happily contribute my existing code for that purpose. I'm interested what you think about the current setup and the idea of starting an official GitHub Action repository.
@nicorikken Yes, I suggest we setup something like https://github.com/oss-review-toolkit/ort-action with the aim to publish it eventually to GitHub action Marketplace
If we still don't want to publish an ORT Docker image, could use a vanilla Ubuntu images, download the compiled JARs from JitPack and install any other packages we need on the fly?
Related to this issue: @mmurto also created his own GitHub action see https://github.com/mmurto/ort-demo/blob/master/.github/workflows/ort.yml
However, I believe a GitHub action should not create SPDX, but SARIF, and use the GitHub API to upload it.
I actually would like the ORT action to be able to output SPDX - highly desired feature within the SBOM community (SPDX, NTIA) I am part of.
@nicorikken Yes, I suggest we setup something like https://github.com/oss-review-toolkit/ort-action with the aim to publish it eventually to GitHub action Marketplace
This sounds really good, also the simple name of the repository itself.
If we still don't want to publish an ORT Docker image, could use a vanilla Ubuntu images, download the compiled JARs from JitPack and install any other packages we need on the fly?
This is possible, and is actually the approach of @boschcrank in https://github.com/boschcrank/oss-review-toolkit as mentioned above. In that repository the ORT code is duplicated and the action.yml is added. I dislike the option of duplicated code from a maintenance point of view, but perhaps we can work around that with a git submodule. For this usecase I think a provided ORT container makes the most sense in startup-time and code maintainability.
Related to this issue: @mmurto also created his own GitHub action see https://github.com/mmurto/ort-demo/blob/master/.github/workflows/ort.yml
Good to link it here. It was shared on Slack and I looked into it. Although I was using a similar setup on my first attempts, I don't think it is flexible. Command flags are used for configuration like the rules.kts which would require some more Action step inputs to handle different cases. Also with it being a Composite step all environment variables have to be passed explicitly, which makes it hard to support all sorts of use-cases. I think the transition to a Docker container Action solves both theses issues, but perhaps I'm missing something. My experience with GitHub Actions is still limited.
Good initiative!
I haven't dug that deep into GitHub Actions to know whether it's possible or easy, but I think for the used Docker image it would be great to have some default image (maybe the Philips one, maybe ORT publishes an official one at some point) but give the option to override it with some flag. I believe that would give the lowest barrier of entry to new projects as the default would often be enough, but I've had projects where pretty heavy modification of the image is necessary, so making that possible would be great.
Good news for sharing such a GitHub Action in your enterprise: https://github.blog/changelog/2022-03-04-sharing-github-actions-within-your-enterprise-is-now-ga/
As discussed in the community meeting, https://github.com/oss-review-toolkit/ort-ci-github-action is public and @tsteenbe asks for testing it to provide feedback.