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

Add GitHub workflow for creating 3rd party dependency list #25

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

sophokles73
Copy link
Contributor

@sophokles73 sophokles73 commented Jan 25, 2024

Adresses #39

A GitHub workflow has been added which determines these by means of the Eclipse Dash license tool.

DO NOT REVIEW YET, THIS IS AN EXPERIMENT FOR NOW

@sophokles73 sophokles73 force-pushed the add_dependencies_check branch 7 times, most recently from cacea24 to c66a428 Compare January 25, 2024 16:34
@sophokles73
Copy link
Contributor Author

My overall intention is to have the following behavior:

  • The build and test workflow should not require all 3rd party deps to be checked, i.e. it should succeed if the code compiles, the tests succeed and the linter does not complain.
  • The check 3rd party deps workflow should succeed if all deps have been vetted successfully. In that case, there is no need to keep a record of the checks.
  • The check 3rd party deps workflow should fail, if any of the deps cannot be vetted successfully. In that case, we should keep a record of the output created by the Dash license tool as an attachment to the workflow run. Having the workflow fail in this case makes it easier to detect that we need to work on the deps, because we can easily spot the failed runs based on their visual markup on GitHub and the fact that we receive a mail for the failed run.

@AnotherDaniel @stevenhartley @PLeVasseur
Does this make sense to you?

@sophokles73 sophokles73 force-pushed the add_dependencies_check branch 4 times, most recently from 5e10fd7 to 0f8b843 Compare February 9, 2024 12:47
@PLeVasseur
Copy link
Contributor

@AnotherDaniel @stevenhartley @PLeVasseur Does this make sense to you?

Yup, seems reasonable to me 🙂

@SebastianSchildt
Copy link

For the second step - piping the dash input file through dash, we do have an Action

https://github.com/eclipse-kuksa/kuksa-actions/tree/main/check-dash

here is an example how to use it https://github.com/eclipse/kuksa.val/blob/cc2e0a67af497685cbcb3d92700f85359f8eab87/.github/workflows/kuksa_databroker_build.yml#L239

And here https://github.com/eclipse/kuksa.val/actions/runs/8230232480 is an example of the outputs, see "Dash data" artefact, as well as "Bill of Material Check summary"

it can't do Dash ticket creation (yet).

Feel free to use from our repo, or just "copy & paste" it over here, it is OSS after all :). I would just assume this pattern will be used in many uproto repos, so likely a bit of reusability would be good (which is how we ended up with a common action)

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

Successfully merging this pull request may close these issues.

3 participants