Gradle+CLI: configurability issues

[renaud-vmg]

NOTE: this assumes the CLI is run against a repository/target with no yml file; this is by design.

Situation

As-is, the CLI appears to target a very specific data "subset" with the Gradle analysis module.

If we look at https://github.com/fossas/fossa-cli/blob/master/builders/gradle/gradle.go, the only configurable part of it is GRADLE_BINARY, and it's configured with an environment variable, not a CLI argument. Unfortunately, in the case of CICD-driven analysis against any project of a certain nature, there can be issues:

• analysis against a different directory structure than the expected one (module not at the root of the repository/analysis target) would instantly fail
  • in this case, we'd need to be able to configure the FOSSA analysis' root directory
    • note that this doesn't affect our environment; this use case is theoretical in nature
  • I understand that module_path may be the answer to this, but the documentation is not clear on this; it looks to me more as an alternate source path for the actual FOSSA analyzer code
• analysis of a multi-module (Gradle modules) project would possibly pull in transitive dependencies we don't care for, especially in the case of rogue build modules in a given source structure
  • in this case, we'd need to be able to tell fossa which submodule to target in order to have the proper transitive dependency tree calculated
    • furthermore, we'd need to be able to provide gradle with command-line arguments, since those can influence the dependency tree calculation

If I read the documentation correctly, without a .yml file, I can't configure a target module for analysis (say, :app:dependencies for example). Unfortunately, in cases where a user/client wants to run FOSSA against a repository that has no clue FOSSA even exists, it's kind of painful, and so is providing a default yml or generating one at build time.

The Request

Provide a way to configure a given module's running arguments. Hopefully the same parser can be reused with multiple modules and change its analysis based on which module is selected, but that's an implementation detail.

[elldritch]

One thing I've struggled with from a UX design perspective is figuring out what these CLI arguments would look like. Right now, the CLI supports analysing multiple FOSSA modules from the command line, which makes it difficult to specify something like Gradle arguments (you'd need a separate set of arguments for each FOSSA module). One thing I'm considering is dropping the multi-module support when invoked from the command line and require that users invoke the CLI multiple times if they want to analyse multiple FOSSA modules.

What would some example invocations look like of your ideal version of the FOSSA CLI?

[renaud-vmg]

Here's my take:

• Multiple calls, one for each module, is my preferred solution.
  • I am of the opinion that I should be able to tell FOSSA to analyze parts of a source tree as I want and to have the datasets go where I want.
  • Bonus: can analyze multiple natures from the same repository, so shared repos for iOS+Android+Node (ObjC+JavaDroid+ECMAScript, whatever) could have different FOSSA WebUI targets for different teams to look at; for example, the Web team wouldn't have to see noise from Android and iOS, and so on
• However, simple multimodule invoke should also be an option, if people want it
  • If it's already integrated within the user habits, no need to kill it
  • Probably useful to expand on it and give more options
• Here's where I go nuts: for multi-module, you could go environment variables that contain the whole configuration string, comma-separated because of task requirements in Gradle and/or other tools such as yarn (task group separators being : in Gradle after all), for each module one wants to configure.

[renaud-vmg]

Per a Zoom with Kevin:

  - name: gradle-easy-config-example
    path: build.gradle
    type: gradle
    project_name: A_Cool_Thing #not a req
    options:
      target: {app//.//thing//otherthing//allthethings}
      scopes: {implementation,api,test//all}

And the cli version:

FOSSA_API_KEY=athing fossa --baseconfig="name:thing;path:thing;type:thing;project_name:thing" --options="target:thing;scopes:thing"