fossas / fossa-cli Goto Github PK

This will be the start of a plugin architecture, where arbitrary commands can provide output to fossa upload and let the FOSSA CLI take care of authentication, constructing the API endpoint, etc.

This will allow end users to run their own analysis tools as long as they conform to the FOSSA source unit specification.

There should be docs that describe the behavior for each builder

For some projects, you may not want to activate all scanners.

Otherwise, users that don't have SSH set up with GitHub well get a permission denied error when they try to go get the fossa-cli project (because go get automatically runs git submodule update --init --recursive.

We've got a good framework for manual integration testing, but there's a lot of room for improvements here:

• Run integration tests automatically in CI.
• Set up golden files in integration tests and CI so that we know when output changes occur.
• Refactor effecting code to take a service-provided implementation (in preparation for unit tests).
• Add automatic unit tests (for pure logic such as parsing).

• depth
• origin path

Our $ locator separator should be a below-the-line abstraction.

Some feedback on either:

1. Project does not exist, ask the user to import into FOSSA
2. Overwrite it with the --project flag or cli.project config variable

Currently it just displays "unauthorized"

Builders are hard to test right now because they do a lot of IO. In particular:

• Reading manifests from the filesystem
• Reading environment variables for user-defined binaries
• Reading shell output from build tool processes

To set up unit tests, we need to refactor all effecting functions to use a service provider instead, so we can mock out the service provide with pure implementations at test time.

This looks like a good use case for dependency injection, if we find something exceptionally light weight. I'd rather keep things simple, and at this point we could just create a service that's always passed to the builders (maybe as a public property in all of their structs, or in the Initialize method?).

Right now, we expect entry point paths to be folders to the working directory of the project. We optionally allow this to be a file only if the file's name follows the convention of the build system (e.g. if it's package.json for nodejs or build.sbt for sbt). The code that handles this is in //cmd/fossa/main.go under resolveModuleConfig.

This is not particularly intuitive behaviour because users may expect to be able to provide the path to their custom-named manifest (for example, a Maven build manifest may be named my-manifest.xml rather than pom.xml). There are two approaches to this:

1. Require that entry points must be directories. This behaviour is consistent with the Go compiler's requirements.
2. Call os.Stat on the entry point. If the entry point is a file (presumably because it's a manifest), call filepath.Dir on the entry point.

Approach (2) adds complexity and convenience, approach (1) reduces complexity and improves predictability.

In many instances, I may want to simply define a module as a "vendorized" dependency.

  - name: rails
    path: Gemfile
    type: ruby
  # vendorized nodejs module required by rails-ujs
  - name: actioncable
    path: actioncable/package.json
    type: vendor
  - name: rails-ujs
    path: actionview/package.json
    type: nodejs

The behavior should be:

1. If I have a vendorized dep at a certain path, other builders should ignore it (possibly in fossa init)
2. Vendorized deps should avoid being built
3. Vendorized deps should be treated as a dep of the top-level src unit (possibly returned in a VendorizedDeps json entry), and transformed into a locator

There's still a use case for succeeding when --allow-unresolved is set; we should just upload all locators in unresolved form.

Instead of parsing output, we could parse the component.json files that are installed in vendor/. This could be less brittle and a softer reliance on composer version or output.

This slows down dep ensure tremendously.

There are a few common build utilities that should be refactored:

• Checking which command to run (given a default, some fallbacks, and an environment variable)
• Searching for project manifests
• Running commands in a specified directory, and getting stdout and stderr as strings.

Eclipse functions of license-cli

i.e. fossa --modules cmd/influx vs fossa --modules go:cmd/influx

We've got a lot of great testing fixtures right now, but none of them run automatically. We need to set up a script to automatically build and run FOSSA against these fixtures, and compare any output against golden files.

fossa should have integration tests running across a variety of tooling versions so we can test, build and document compatibility with different versions of mvn, npm, and etc...

This should be represented as a matrix of supported versions in our docs.

Lots of solutions for this:

https://gist.github.com/steinwaywhw/a4cd19cda655b8249d908261a62687f8
https://github.com/jpillora/installer

Steps to reproduce:

1. Download alvin-huang/go-hello-world.
2. Download fossa v0.3.1.
3. Mount go-hello-world in its $GOPATH location within the golang:1.10-stretch container
4. Run fossa analyze --modules go:. from within the go-hello-world directory in the container.

Interestingly, fossa works if you build it from source from within the Docker container. I suspect this has to do with our usage of KyleBanks/depth for import analysis -- something about a difference between the environment's Go and the Go used to compile fossa is breaking things.

The -o flags behavior should perform as follows:

1. If a param is specified i.e. fossa -o output.json, it should write to the output file.
2. If a the flag is run alone with no param i.e. fossa -o it should write to stdout

Read configuration options from .fossa.yml.

Improve README and docs, some inspiration:

• https://github.com/matiassingers/awesome-readme

Add a "who's using" section with customer logo list.

When pushing provided builds to FOSSA, if the enable provided builds checkbox is not checked, fossa-cli gives me:

CRITICAL Upload failed: bad server response ("\"This project is not configured to accept Provided Builds. Set `require_mediated_dependencies` to `true` in order to enable\"")

However, this is not exactly true. Once you check the checkbox for enable provided builds it will allow you to push without having to check the box for prefer mediated data. Should these two settings be turned on and off together?

https://github.com/rhysd/go-github-selfupdate

In particular, we need to improve how we infer the project and revision. These don't currently happen correctly:

1. Calls to git should run in the directory of the module, not the working directory of the process.
2. There seems to be some bug where we don't correctly prefix git+ to certain projects. My suspicion is an issue with special characters. We should have a strongly typed format for locators that we pass around, rather than inferring locator sections using delimited string.

Our tree resolution relies on the gopackage getting installed, so we must ensure go get is run.

Error messages are currently geared towards being clear for CLI developers, not end users. The general theme is that some very general failure modes (e.g. bad server response code) usually occur for very specific reasons (e.g. user forgot to upload this revision). Here are some improvements:

• Better error message for a locator that isn't found (usually due to bad locator configuration or VCS inference)
• Better error message for invalid API key is invalid during fossa test
• Running fossa test on a non-existent revision only responds with 500
• Distinguish between "user has not uploaded provided build" and "FOSSA has not yet applied the provided build" during fossa test

Add a command that re-writes analyze.modules in .fossa.yml based off any discovered modules.

• Ensure interface to easily serialize and de-serialize config from/to yml
• Add fossa-cli comment header on config write
• Rename builder.InferModule(target string) to builder.DiscoverModules(dir string)
• Implement builder.DiscoverModule for node
• Add behavior to default cmd if we are missing critical config
• Add flag to default cmd to force updating config
• Implement "fail-open" flag if a module has an error in default cmd
• fully implement DiscoverModules across all currently-supported build systems

As we're going to have more commands operate as a REST client, there should be a common set of utils to make requests and handle common responses (i.e. invalid API keys, etc...)

Best way to explain CLI commands is a nice little demo gif!

Add ability to submit build results to a fossa instance

When running in debug mode, interactive widgets like spinners make output really annoying to read. The two flags that would help are:

• --no-spinner (perhaps --no-interactive or --no-ansi?): turn off spinners and other ANSI widgets
• --no-color: turn off colour codes.

Some ideas:

• Install script for curl | bash or other one-liner. We can probably take the script from jpillora/installer.
• npm install -g @fossa/cli
• brew install @fossa/cli

Some references:

• https://gist.github.com/steinwaywhw/a4cd19cda655b8249d908261a62687f8

fossa --modules go:modula go:moduleb

I want my modules to have more metadata than just name -- how about Url, Direct Deps and etc?

Right now, we buffer the shell command's stdout and process it all at once after the command completes. Ideally, we would process the output line-by-line as it becomes available.

This is most important for the SBT and Maven plugins, which are incredibly slow. It's also theoretically useful for Ruby and Composer, although the need is less pressing here.

Advantages of stream processing:

• Avoid keeping a stdout buffer
• Show interactive progress as the shell command runs (at the very least in debug mode)

When uploading and creating a URL, fossa-cli should detect the local branch instead of defaulting to master. See it hardcoded here: