gh-dependency-report
gh-dependency-report copied to clipboard
Scheduled and ad-hoc dependency audit MVP
In order to truly judge whether this CLI extension is fit for a v1.0.0
milestone, it needs to fulfill an end rather than just being a means. One of the motivations for building this extension was to make it easier for GitHub enterprises to audit dependencies and take action. This issue aims to capture the requirements and design of a minimally viable product that can run on a schedule and/or ad-hoc to do just that.
Ideation
- The frequency of auditing and addressing issues around licenses is cyclical but could vary depending on the maturity of the enterprise; weekly, monthly, quarterly, semi-annually, annually
- Most enterprises know either the licenses they can or cannot use
- Actions that enterprises might perform when reviewing licenses:
- Acknowledge (ideal case)
- Report / Alert (reasonable response)
- Lock the repository (extreme response)
- It is likely that licenses that have been Report / Alert might not be addressed before subsequent runs, so detecting and escalating these Report / Alert might be necessary
- In the case of Report / Alert, this might be something that customers want done within the repository the dependency resides within OR in the repository where the workflow lives
- Once the report is generated and analyzed, a digest of findings and actions taken would be helpful for executive review
- If the workflow fails to run, then someone needs to be notified to follow up on it (
workflow_run
failures)
Requirements
- [ ] GitHub Actions workflow supporting
workflow_dispatch
andschedule
triggers - [ ] Takes in a list of organizations and/or users
- [ ] Takes in a list of spdx license identifiers and an action
- [ ] Generates and preserves
andyfeller/gh-dependency-report
report as a workflow attachment - [ ] ...
https://github.com/andyfeller/gh-dependency-report/actions/runs/1972331824 was initial run where I got one of the reports stored as an artifact. With that being done, I'm rethinking about how this workflow should work:
- should there be a matrix of runs that are all uploaded?
- how do you process multiple reports?
- should the extension support adding results to 1 report?
I want to think on https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts and https://github.com/actions/upload-artifact a bit longer