Skip to content
This repository has been archived by the owner on Apr 1, 2022. It is now read-only.

Monorepo fossa test and fossa report fix #290

Merged
merged 4 commits into from
Jul 19, 2021
Merged

Conversation

jssblck
Copy link
Member

@jssblck jssblck commented Jul 19, 2021

Overview

Update fossa test and fossa report to work with monorepo projects:

  • When waiting for build, also wait for a monorepo build. Move on when either a standard or monorepo build completes.
  • Make dependencies optional when parsing attribution report JSON from the server.

Acceptance criteria

  • Support fossa test for monorepo projects.
  • Support fossa report for monorepo projects.

Testing plan

Ran fossa report against a monorepo project in staging:

cabal run fossa -- report attribution --json --endpoint '<url>'  --fossa-api-key <key> --project 'aosp-mini' --revision 1625264228

This reported expected results:

{"project":{"name":"aosp-mini (enricozb)","revision":"1625264228"},"directDependencies":[],"licenses":{"Apache-2.0":"This license is not associated with a known package in your project.","MIT-CMU":"This license is not associated with a known package in your project.","BSD-3-Clause":"This license is not associated with a known package in your project.","GPL-3.0+":"This license is not associated with a known package in your project.","MIT":"This license is not associated with a known package in your project.","GPL-2.0":"This license is not associated with a known package in your project.","BSD-4-Clause-UC":"This license is not associated with a known package in your project.","Public-domain":"This license is not associated with a known package in your project.","BSD-4-Clause":"This license is not associated with a known package in your project.","ISC":"This license is not associated with a known package in your project.","Bison-exception-2.2":"This license is not associated with a known package in your project.","BSD-2-Clause":"This license is not associated with a known package in your project."},"deepDependencies":[]}

Ran fossa test against a monorepo project in staging:

cabal run fossa -- test --endpoint '<url>'  --fossa-api-key <key> --project 'aosp-mini' --revision 1625264228

This correctly failed the test and denied with four issues.

I then tested both commands with a non-monorepo project and they similarly worked as expected.

Risks

Touching this area of the code could cause issues with fossa test and fossa report on non-monorepo projects, but I think that the changes are defensive enough that this is unlikely.

Checklist

  • I added tests for this PR's change (or confirmed tests are not viable).
  • I linted and formatted (via haskell-language-server) any haskell files I touched in this PR.
  • I updated 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.
  • I linked this PR to any referenced GitHub issues, if they exist.

@jssblck jssblck requested review from a team and cnr and removed request for a team July 19, 2021 18:22
Copy link
Contributor

@cnr cnr left a comment

Choose a reason for hiding this comment

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

generally LGTM -- diff is much much smaller than expected, which is great.

question about why waitForBuild throws an error for monorepo projects, and an edge case I'm curious about:

Is the Fossa.getLatestBuild API call the one that fails/throws for monorepo projects? If so, given the following steps:

  • User scans a new project without the --experimental-enable-monorepo flag
  • User scans the project again with the --experimental-enable-monorepo flag

..what's the behavior? will waitForBuild incorrectly succeed on this monorepo project?

@jssblck
Copy link
Member Author

jssblck commented Jul 19, 2021

@cnr

Is the Fossa.getLatestBuild API call the one that fails/throws for monorepo projects? If so, given the following steps:

Yes, it is. Monorepo projects don't have a build task, so the endpoint returns a 404 iirc.

  • User scans a new project without the --experimental-enable-monorepo flag
  • User scans the project again with the --experimental-enable-monorepo flag

..what's the behavior? will waitForBuild incorrectly succeed on this monorepo project?

The second scan will actually fail, assuming the same project locator for both scans. Currently, standard and monorepo scans are stored completely differently in the system, so if a project already exists as a standard project the monorepo scan fails.

@cnr
Copy link
Contributor

cnr commented Jul 19, 2021

Thanks for clarifying 👍 . That was helpful in correcting my understanding of how monorepo projects work

@jssblck jssblck merged commit f0df0e3 into master Jul 19, 2021
@jssblck jssblck deleted the monorepo-test-report-fix branch July 19, 2021 19:12
meghfossa pushed a commit that referenced this pull request Jul 22, 2021
* Support monorepo scans in `fossa test` and `fossa report`
* Make attribution report dependencies optional
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants