datatracker
datatracker copied to clipboard
feat: Create an SBOM for releases
It's kinda difficult to check if this works, since this workflow always fails in my repo clone.
@jennifer-richards https://github.com/larseggert/datatracker/actions/runs/3052008565/jobs/4937025616#step:6:22 fails with
Migrations for 'meeting': ietf/meeting/migrations/0054_auto_20220915_0308.py - Alter field time_zone on meeting
Any idea why?
It looks like the base for that branch is out of date. On main, the urllib3 exception is converted to a warning (https://github.com/ietf-tools/datatracker/blob/5b6695a04c46e1756183272e8da4195f1ebea1a7/ietf/settings.py#L16) and the ci-run-tests workflow was modified to use the return value from the makemigrations check instead of failing if there's anything on stdout (https://github.com/ietf-tools/datatracker/blob/5b6695a04c46e1756183272e8da4195f1ebea1a7/.github/workflows/ci-run-tests.yml#L47).
So merge in main?
Weird. It looked to me like it was up-to-date with main
. Trying it now though.
May need to update your fork to see the changes.
Still happening: https://github.com/larseggert/datatracker/actions/runs/3052008565/jobs/4938157088#step:6:22
I don't get why. git diff origin/main
shows me no changes other than to the workflow after pulling origin/main
.
Yeah, it looks like it should be working. Looking at it.
It looks like it's checking out https://github.com/larseggert/datatracker/commit/0ba50999d93f1bd210c15d5590cf1d9a8ca89e08 to run the tests. That is old and not the branch in this PR. Not sure why that's happening.
(I hadn't noticed this earlier, so my suggestions that the base for this work was out of date were incorrect. The new work all has the fixes I pointed at already, it's just not what's being tested by those runs.)
Thanks for debugging this! I guess I need to figure out how to manually kick off a workflow run at the right revision
There should be a pull-down on the 'start workflow' button that lets you choose a branch
Yep, just found that! I used the wrong branch before :(
OK, this seems to work. See https://github.com/larseggert/datatracker/actions/runs/3060670758/jobs/4939479571#step:14:1
Codecov Report
Merging #4447 (272b8de) into main (bc1cba1) will increase coverage by
0.00%
. The diff coverage is83.72%
.
@@ Coverage Diff @@
## main #4447 +/- ##
=======================================
Coverage 88.47% 88.48%
=======================================
Files 296 296
Lines 39795 39806 +11
=======================================
+ Hits 35208 35221 +13
+ Misses 4587 4585 -2
Impacted Files | Coverage Δ | |
---|---|---|
ietf/review/utils.py | 89.57% <ø> (-0.03%) |
:arrow_down: |
ietf/doc/utils.py | 88.05% <77.77%> (-0.16%) |
:arrow_down: |
ietf/doc/views_doc.py | 91.18% <84.37%> (+0.40%) |
:arrow_up: |
ietf/doc/models.py | 88.16% <100.00%> (+0.01%) |
:arrow_up: |
ietf/doc/templatetags/ballot_icon.py | 84.82% <100.00%> (ø) |
|
ietf/doc/views_search.py | 89.23% <0.00%> (-0.42%) |
:arrow_down: |
ietf/nomcom/utils.py | 91.30% <0.00%> (-0.25%) |
:arrow_down: |
ietf/utils/mail.py | 80.09% <0.00%> (+0.46%) |
:arrow_up: |
ietf/person/utils.py | 86.98% <0.00%> (+0.59%) |
:arrow_up: |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
Hi Lars - It's not immediately clear what this is going to concretely provide for us? What does the microsoft SBOM tool produce and what's going to consume what's produced?
https://www.cisa.gov/sbom
Looking at your latest build, it generates a table in the build logs with a count for each dependency type. Does it provide any output that can be useful to be included as part of a release? What benefits does it bring over something like GitHub dependency scans, which already provide automated alerts and suggested fixes for dependencies with vulnerabilities?
The benefits are that you can check vulnerabilities for installed software, e.g. when you need to determine if you are affected by something like logjam.
https://github.com/ietf-tools/datatracker/network/dependencies
For the datatracker the link Nick points to is probably enough, yes?
But we should talk about providing SBOM for software we expect to be widely installed on other systems, such as xml2rfc. The end goal of the SBOM idea is to make it easier to write a tool that would scan a machine for anything that might be suffering a vulnerability. Could get used by state-validation software for example.
See the comment thread (and I think we had some direct conversation about this at some point)? I'm not seeing value for this for the datatracker over what github already provides?
An SBOM for xml2rfc makes more sense to me.
Closing this per discussion at the 116 codesprint.