Fast, portable and reliable dependency analysis for any codebase. Supports license & vulnerability scanning for large monoliths. Language-agnostic; integrates with 20+ build systems.
This adds a little automated testing around analyzing jars in containers with millhone.
It also modifies the way we look up filepaths in tar files to normalize them. We avoided this in the past because I guess most of the tarballs we were scanning had everything at the root level so filepath separators didn't cause an error. This isn't true for newer images I've made with docker save.
Acceptance criteria
There are now automated tests that exercising reading jars out of containers with millhone and processing them in the CLI.
Testing plan
This PR is just tests to run. Manual tests have been done on the branches this is stacked on top of.
Risks
None.
Metrics
Is this change something that can or should be tracked? If so, can we do it today? And how? If its easy, do it
[x] I added tests for this PR's change (or explained in the PR description why tests don't make sense).
[x] If this PR introduced a user-visible change, I added documentation into docs/.
[x] If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
[x] If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
[x] If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
[x] If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.
Overview
This adds a little automated testing around analyzing jars in containers with millhone.
It also modifies the way we look up filepaths in tar files to normalize them. We avoided this in the past because I guess most of the tarballs we were scanning had everything at the root level so filepath separators didn't cause an error. This isn't true for newer images I've made with
docker save.Acceptance criteria
There are now automated tests that exercising reading jars out of containers with millhone and processing them in the CLI.
Testing plan
This PR is just tests to run. Manual tests have been done on the branches this is stacked on top of.
Risks
None.
Metrics
Is this change something that can or should be tracked? If so, can we do it today? And how? If its easy, do it
References
Checklist
docs/.docs/README.msand gave consideration to how discoverable or not my documentation is.Changelog.md. If this PR did not mark a release, I added my changes into an# Unreleasedsection at the top..fossa.ymlorfossa-deps.{json.yml}, I updateddocs/references/files/*.schema.jsonAND I have updated example files used byfossa initcommand. You may also need to update these if you have added/removed new dependency type (e.g.pip) or analysis target type (e.g.poetry).docs/references/subcommands/<subcommand>.md.