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

feat: add SBOM-based dependency diff workflow #14

Merged
merged 5 commits into from
Oct 9, 2023

Conversation

ThorbenLindhauer
Copy link
Member

- contains some changes of the following commits in accumulating files
  (e.g. dist/index.js, package.json)

related to camunda/camunda-bpm-platform#2781
@ThorbenLindhauer
Copy link
Member Author

I have restructured the PR into five meaningful increments. Note that the first commit contains some content in shared files (e.g. dist/index.js, package.json) that is only used by the subsequent commits. Also note that the individual commits may not represent and individually executable and working state. The primary purpose of this structure is to make code review easier.

@ThorbenLindhauer ThorbenLindhauer marked this pull request as ready for review September 29, 2023 09:23
Copy link
Member

@danielkelemen danielkelemen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really nice! I added some minor comments, mostly about obvious code smells and a few questions.

💬 Since it contains a lot of code it might be good to see some details in the job log in case we need to look into something. GitHub has the log grouping feature which makes reading big logs easier. Maybe we could use it here?

Some ideas (link):

  • 🔧 Group the git and maven executions.
  • 🔧 We could also print the head and base sbom in groups. Maybe print some intermediate infos during analysis.

What do you think?

Comment on lines +30 to +44
const partialPaths = [
'componentDetails:../java-dependency-check/component-details.hbs',
'componentDiff:../java-dependency-check/component-diff.hbs',
'componentTree:../java-dependency-check/component-tree.hbs',
'componentVersion:../java-dependency-check/component-version.hbs'
];

const partials = partialPaths.reduce(
(result, input) => {
[ partialId, partialPath ] = input.split(':');
result[partialId.trim()] = readFile(partialPath.trim());
return result;
},
{}
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💬 Interesting way of doing this :) But it does the job.
I guess it's because it uses the (almost) same format as the workflow parameter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if there's a more elegant way to convert these parameters into a map. I have rather basic Javascript standard library knowledge (and google skills).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's okay!
I later realized that it uses the same format as the workflow input parameter (which is just a string not a JSON object or map), so it makes sense. 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓Why do we need this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is generated by ncc build index.js -o dist that bundles and minifies code along with the npm dependencies. I cannot tell exactly why it is like that, it appeared with adding one of the dependencies. My guess would be that this is a transitive dependency of one of the dependencies and it has some configuration that prevents bundling/minification.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay, thanks.
I really tried to understand why it's needed but couldn't figure it out. 😀


var args = process.argv.slice(2); // first two arguments are the executable and the JS file

if (args.length != 3) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧

Suggested change
if (args.length != 3) {
if (args.length !== 3) {

core.info(`Dependency diff:`);
core.info(diff.fullDiff);

octokit.rest.issues.createComment({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓Should we maybe wait for this?

Suggested change
octokit.rest.issues.createComment({
await octokit.rest.issues.createComment({

dependency the traversal belongs
*/

var componentDiff = sbomDiff.getComponentDiff(baseComponent, comparingComponent);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧

Suggested change
var componentDiff = sbomDiff.getComponentDiff(baseComponent, comparingComponent);
let componentDiff = sbomDiff.getComponentDiff(baseComponent, comparingComponent);

Comment on lines 9 to 10
var baseComponent = actual.baseComponent;
var comparingComponent = actual.comparingComponent;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧

Suggested change
var baseComponent = actual.baseComponent;
var comparingComponent = actual.comparingComponent;
const baseComponent = actual.baseComponent;
const comparingComponent = actual.comparingComponent;


const actualChanges = Object.assign({}, actual.changedDependencies);
const unmatchedChanges = [];
var allChangesMatch = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧

Suggested change
var allChangesMatch = true;
let allChangesMatch = true;


expect(components.size).toEqual(19);

var numThirdPartyComponents = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
var numThirdPartyComponents = 0;
let numThirdPartyComponents = 0;


expect.extend(sbomMatchers);

describe("SBOM diff", () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧 These tests could also have the given-when-then comments.

Comment on lines 14 to 24
mkdir -p target/diff

mvn -s "$1" --no-transfer-progress org.cyclonedx:cyclonedx-maven-plugin:2.7.9:makeAggregateBom

echo "SBOM generated for github ref HEAD"

cp target/bom.json target/diff/head.json
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💬 The job log output is pretty big, maybe we could take advantage of GitHub log grouping? (I haven't tried this)

Suggested change
mkdir -p target/diff
mvn -s "$1" --no-transfer-progress org.cyclonedx:cyclonedx-maven-plugin:2.7.9:makeAggregateBom
echo "SBOM generated for github ref HEAD"
cp target/bom.json target/diff/head.json
echo "::group::SBOM head"
mkdir -p target/diff
mvn -s "$1" --no-transfer-progress org.cyclonedx:cyclonedx-maven-plugin:2.7.9:makeAggregateBom
echo "SBOM generated for github ref HEAD"
cp target/bom.json target/diff/head.json
echo "::endgroup::"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*I mixed up the jobs, the output is actually not that big as I thought.


{{#each diff.addedDependencies}}
{{#if thirdParty}}
- [ ] {{name}}:{{>componentVersion}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧

Suggested change
- [ ] {{name}}:{{>componentVersion}}
- [ ] {{name}}: {{>componentVersion}}

@ThorbenLindhauer
Copy link
Member Author

Re log grouping:

I can have a look and add it for the git and Maven output. I wouldn't log the SBOM files though. They are ~10,000 lines, which makes searching and browsing them very hard in the log file. github also adds the timestamp to each line so it's rather impossible to copy them into an editor from there. Instead I decided to add them as workflow artifacts (check the zip file in the build summary). I think that is easier to work with.

@ThorbenLindhauer
Copy link
Member Author

@danielkelemen I have applied all the review hints that I didn't comment on and I have added log grouping to the step that generates SBOMs (see https://github.com/camunda/camunda-bpm-platform/actions/runs/6433372444/job/17470293552?pr=3581). Please re-review and let me know what you think about the items I commented on.

Copy link
Member

@danielkelemen danielkelemen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! 👍

The zip download is better than the logging the SBOMs, I agree.

@ThorbenLindhauer ThorbenLindhauer force-pushed the 2781-dependency-updates branch from e8162e9 to 3dfe8c2 Compare October 9, 2023 07:44
@ThorbenLindhauer ThorbenLindhauer merged commit 08cfc4f into main Oct 9, 2023
1 check passed
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.

2 participants