Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduled and ad-hoc dependency audit MVP #16

Open
andyfeller opened this issue Mar 5, 2022 · 2 comments
Open

Scheduled and ad-hoc dependency audit MVP #16

andyfeller opened this issue Mar 5, 2022 · 2 comments
Assignees
Milestone

Comments

@andyfeller
Copy link
Owner

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.

@andyfeller andyfeller added this to the v1.0.0 milestone Mar 5, 2022
@andyfeller andyfeller self-assigned this Mar 5, 2022
@andyfeller
Copy link
Owner Author

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 and schedule 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
  • ...

@andyfeller
Copy link
Owner Author

andyfeller commented Mar 14, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant