-
Notifications
You must be signed in to change notification settings - Fork 173
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
Tie dynamic linking all together #818
Conversation
We're using `<||>` to select the first success, so we need to explicitly fail ones that don't work instead of recovering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a short drive-by review, left some comments, nothing too significant.
-- When adding new tactics in the future, ensure that they fail (through diagnostics) if they're not the last link in the chain. | ||
-- <||> selects the first item to succeed without a diagnostic error. | ||
resolved <- rpmTactic root file <||> debTactic root file <||> apkTactic table file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they should just always fail. That way, ordering is not critical for success.
-- When adding new tactics in the future, ensure that they fail (through diagnostics) if they're not the last link in the chain. | |
-- <||> selects the first item to succeed without a diagnostic error. | |
resolved <- rpmTactic root file <||> debTactic root file <||> apkTactic table file | |
-- When adding new tactics in the future, ensure that they fail through diagnostics. | |
-- <||> selects the first item to succeed without a diagnostic error. | |
resolved <- rpmTactic root file <||> debTactic root file <||> apkTactic table file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idea for a utility:
dsum [a, b, c] = a <||> b <||> c
Naming comes from asum
, but we should probably find a better name.
I think it could be implemented as
data DSumStart = DSumStart
instance ToDiagnostic DSumStart where
renderDiagnostic _ = "dsum was called with an empty list"
dsum = foldr (<||>) (fatal DSumStart)
@scruffystuffs since you did a drive by I can't use the bot to select anyone else 😬 if you don't have time to review this let me know and I'll post in Slack. |
Oops. Yeah I'm pretty swamped atm, you probably need someone else to review this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left few optional nits. There is minor open question re scan summary, please address it via comment/or/commit before merging.
additionalSourceUnits = mapMaybe (join . resultToMaybe) [manualSrcUnits, vsiResults, binarySearchResults] | ||
traverse_ (Diag.flushLogs SevError SevDebug) [vsiResults, binarySearchResults, manualSrcUnits] | ||
additionalSourceUnits = mapMaybe (join . resultToMaybe) [manualSrcUnits, vsiResults, binarySearchResults, dynamicLinkedResults] | ||
traverse_ (Diag.flushLogs SevError SevDebug) [vsiResults, binarySearchResults, manualSrcUnits, dynamicLinkedResults] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want the dynamic deps results to show in scan summary, we would need to update this type, https://github.com/fossas/fossa-cli/blob/master/src/App/Fossa/Analyze/Types.hs#L40. And also few methods in App.Fossa.Analyze.ScanSummary
.
If this is not in the AC of the ticket, ignore this.
@meghfossa thanks for the comments, it now integrates cleanly with the scan summary:
|
Overview
Ties dynamic linking together.
Also removes
APK
support, as we found that to have unacceptable performance when usingsyft
.We'll make a ticket to revisit APK support when/if users request it.
Acceptance criteria
Support reporting dynamically linked dependencies.
Testing plan
Manual testing (todo: fill this in)
Testing on Ubuntu
I set up an ubuntu docker container which could build the CLI.
I then ran the following command:
I verified that the results appear as expected. The FOSSA UI shows the following results:
I verified the results by running
ldd
and looking up each package manually:Testing on Fedora
I set up a Fedora installation inside Parallels Desktop. I then set up the Haskell toolchain and built the CLI.
I then ran the following command:
I verified that the results appear as expected. The FOSSA UI displays the following results:
I verified the results by running
ldd
and looking up each package manually:Risks
Not very risky. Adds a new additional source unit.
References
Closes https://github.com/fossas/team-analysis/issues/886
Checklist
docs/
.Changelog.md
if this change is externally facing. If this PR did not mark a release, I added my changes into an# Unreleased
section at the top.*schema.json
if I have made changes for.fossa.yml
,fossa-deps.{json, yaml, yml}
. You may also need to update these if you have added/removed new dependency (e.g. pip) or analysis target type (e.g. poetry).