feat(DATAGO-115000): Generic Support for fossa cli flags. Implemented path and config here. #58

johnvincentcorpuz · 2025-12-22T16:20:29Z

Summary

Adds support for fossa.config and fossa.path parameters via a new JSON-based configuration system, enabling monorepo per-project scanning with custom FOSSA configurations.

Key Features

✨ New Parameters

✅ fossa.path - Specify base directory to scan (for monorepos)
✅ fossa.config - Specify custom .fossa.yml path

🏗️ Architecture Improvements

✅ JSON-based configuration (fossa-params.json) - Declarative parameter definitions
✅ Testable parser script (parse-fossa-params.sh) - Standalone, reusable logic
✅ Comprehensive test suite (test-parse-fossa-params.sh) - 11 tests, all passing
✅ Complete documentation - READMEs for both sca-scan and fossa-scan

Changes

New Files

fossa-params.json - Parameter configuration with descriptions and examples
parse-fossa-params.sh - Reusable parameter parser
test-parse-fossa-params.sh - Test suite
fossa-scan/README.md - FOSSA action documentation
sca-scan/README.md - SCA scan action documentation

Modified Files

action.yaml - Uses new parser script

Problem Solved

When scanning monorepo plugins, FOSSA CLI previously picked up the root .fossa.yml instead of plugin-specific .fossa.yml files:

Repository Root/
├── .fossa.yml                    # ← Was using this (wrong!)
├── sam-mongodb/
│   └── .fossa.yml                # ← Should use this (correct!)
└── sam-slack/
    └── .fossa.yml                # ← Should use this (correct!)

Usage Example

- name: Scan Monorepo Plugin
  uses: SolaceDev/solace-public-workflows/.github/actions/sca/sca-scan@main
  with:
    scanners: "fossa"
    additional_scan_params: |
      fossa.path=sam-mongodb
      #fossa.config=config/.fossa.yml #can optionally be set if the path is not in the directory of fossa.path
      fossa.project=SolaceLabs_sam-mongodb
      fossa.branch=PR
    fossa_api_key: ${{ secrets.FOSSA_API_KEY }}

Benefits

For Users

✅ Supports monorepo per-project scanning
✅ Plugin-specific FOSSA configurations
✅ Backward compatible (all parameters optional)
✅ Comprehensive documentation with examples

For Maintainers

✅ Easy to extend - Add parameters by editing JSON, no code changes
✅ Testable - Standalone test suite with 11 test cases
✅ Self-documenting - JSON includes descriptions and examples
✅ Type-safe - Explicit flag vs value parameter types

Adding New Parameters

Now it's trivial! Just add one JSON entry:

{
  "env": "SCA_FOSSA_NEW_PARAM",
  "flag": "--new-param",
  "type": "value",
  "description": "What this parameter does",
  "example": "fossa.new_param=value"
}

Run tests and you're done:

cd .github/actions/sca/fossa-scan
./test-parse-fossa-params.sh

Test Results

🧪 FOSSA Parameter Parser Test Suite
=================================================
✓ Basic flag parameter
✓ Value parameter  
✓ Multiple parameters
✓ Empty value not included
✓ False flag not included
✓ Monorepo use case
=================================================
✅ All 11 tests passed!

Test Plan

All unit tests passing (11/11)
Test with monorepo containing multiple .fossa.yml files
Verify correct config file used when fossa.config specified
Verify correct path scanned when fossa.path specified
Verify backward compatibility when parameters not provided
Test in consumer repo: feat(DATAGO-115000): add FOSSA SCA scanning for monorepo plugins SolaceLabs/solace-agent-mesh-core-plugins#79

Adds support for `fossa.config` and `fossa.path` via the existing `additional_scan_params` mechanism to enable monorepo per-project scanning. Changes: - Add `--path` flag support via `fossa.path` parameter - Add `--config` flag support via `fossa.config` parameter - Both parameters are optional and backward compatible Usage example: ```yaml additional_scan_params: | fossa.path=sam-mongodb fossa.config=sam-mongodb/.fossa.yml fossa.project=my-plugin ``` This allows scanning specific subdirectories with their own .fossa.yml configuration files, which is essential for monorepo workflows where each plugin needs independent FOSSA project tracking. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

Replace individual if-blocks with a loop-based parameter mapping system for easier maintenance and extensibility. Benefits: - Reduces code from ~50 lines to ~35 lines - Adding new parameters now requires only one line - Self-documenting parameter format: ENV_VAR:--flag:type - Maintains backward compatibility Example of adding a new parameter: ```bash "SCA_FOSSA_NEW_PARAM:--new-param:value" ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

Complete refactor to use declarative JSON configuration for FOSSA CLI parameters, making the action more maintainable and easier to extend. **New Files:** - `fossa-params.json` - Declarative parameter mapping configuration - `parse-fossa-params.sh` - Reusable, testable parser script - `test-parse-fossa-params.sh` - Comprehensive test suite (11 tests, all passing) - `README.md` - Complete documentation with examples **Key Improvements:** ✅ JSON-based config - Add parameters without touching bash logic ✅ Self-documenting - Each parameter includes description and example ✅ Testable - Standalone parser script with full test coverage ✅ Safer - Uses indirect expansion instead of eval ✅ Compatible - Works on all systems (no process substitution issues) **Architecture:** ``` User → additional_scan_params → Environment Variables ↓ fossa-params.json (config) + parse-fossa-params.sh (parser) ↓ FOSSA CLI arguments ``` **Adding New Parameters:** Just add one JSON entry - no code changes needed: ```json { "env": "SCA_FOSSA_NEW_PARAM", "flag": "--new-param", "type": "value", "description": "Description here" } ``` **Test Results:** ``` ✅ All 11 tests passed - Basic flag parameters - Value parameters - Multiple parameters - Empty value handling - Boolean flag handling - Real-world monorepo use case ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

- Step-by-step instructions for adding parameters - Test suite execution requirements - Optional test case creation guide - Field-by-field JSON configuration guide 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

Complete documentation covering: - Overview and architecture - Input parameters and usage examples - Parameter conversion system - Monorepo and matrix build examples - Error handling and troubleshooting - Extension guide for adding new scanners 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

Adds the missing --project flag support to allow overriding the FOSSA project name/ID for better monorepo organization. Changes: - Add SCA_FOSSA_PROJECT → --project mapping to fossa-params.json - Add test case for project parameter (13 tests now, all passing) - Update README to document fossa.project parameter - Update monorepo test to verify project flag is included Usage: ```yaml additional_scan_params: | fossa.project=MyOrg_my-project fossa.path=my-project fossa.config=my-project/.fossa.yml ``` This will generate: ```bash fossa analyze --project MyOrg_my-project --path my-project --config my-project/.fossa.yml ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

Implements intelligent parameter filtering so 'fossa test' only receives parameters it supports, while 'fossa analyze' gets all parameters. **Changes:** Schema Update (fossa-params.json v2.0.0): - Add 'commands' field to each parameter: ['analyze'] or ['analyze', 'test'] - Documents which FOSSA commands support each parameter - Shared parameters: branch, revision, project, config - Analyze-only: debug, path, unpack_archives, without_default_filters, force_vendored_dependency_rescans Parser Enhancement (parse-fossa-params.sh): - Add optional 'command' parameter to build_fossa_args() - Filter parameters based on commands array in JSON - Usage: `build_fossa_args "analyze"` or `build_fossa_args "test"` Action Update (action.yaml): - Build separate args for analyze and test commands - Replaces hardcoded test args logic with parser Test Coverage (test-parse-fossa-params.sh): - Add test_command_filtering_analyze() - 3 assertions - Add test_command_filtering_test() - 6 assertions - Verify analyze-only params excluded from test command - **22 tests total, all passing** ✅ **Before:** ```bash # Test args were hardcoded, only supported --revision SCA_FOSSA_TEST_ARGS="--revision ${SCA_FOSSA_REVISION}" ``` **After:** ```bash # Test args built dynamically from same config build_fossa_args "test" # Gets: --branch, --revision, --project, --config build_fossa_args "analyze" # Gets: all parameters including --path, --debug ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

- Add Commands column to Available Parameters table - Document which params work with analyze vs test - Update Field Guide with commands array documentation - Explain command filtering behavior 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

@main

Change from absolute @main reference to relative ./fossa-scan path. This ensures the sca-scan action uses the fossa-scan action from the same branch/commit instead of always pulling from main. **Problem:** When using @specify_fossa_config_path branch: - sca-scan action loaded from branch ✅ - fossa-scan action loaded from @main ❌ (old version) - Result: New parameters not applied **Solution:** Use relative path './fossa-scan' so both actions load from same source. **Before:** ```yaml uses: SolaceDev/solace-public-workflows/.github/actions/sca/fossa-scan@main ``` **After:** ```yaml uses: ./fossa-scan # Relative path from sca-scan directory ``` This is the standard pattern for composite actions referencing local actions. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

@main

Use @specify_fossa_config_path branch reference to test changes. This will be changed back to @main before merging. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

FOSSA CLI doesn't have a --path flag. Instead, use GitHub Actions working-directory to change into the target directory before scanning. **Changes:** Action (action.yaml): - Add working-directory to Fossa - Scan step - Add working-directory to Fossa Test step - Uses ${{ env.SCA_FOSSA_PATH || '.' }} to default to current dir - Log which directory is being scanned Schema (fossa-params.json): - Remove SCA_FOSSA_PATH → --path mapping (invalid flag) - Add note about fossa.path being a special parameter - fossa.path now controls working-directory, not CLI flag Tests (test-parse-fossa-params.sh): - Remove all --path CLI flag assertions - Tests reduced from 22 to 18 (removed 4 --path checks) - All 18 tests passing ✅ Documentation (README.md): - Update fossa.path description to "N/A (working directory)" - Add "Special Parameters" section explaining fossa.path behavior - Clarify it's not a CLI flag but a directory change **Before:** ```bash fossa analyze --path sam-bedrock-agent # ❌ Invalid flag ``` **After:** ```bash cd sam-bedrock-agent # via working-directory fossa analyze # ✅ Scans from correct directory ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

The --branch flag is only supported by 'fossa analyze', not 'fossa test'. Also clarify that fossa.path automatically finds .fossa.yml in that directory. **Changes:** Schema (fossa-params.json): - Change SCA_FOSSA_BRANCH commands from ["analyze", "test"] to ["analyze"] - Add notes explaining fossa.path/fossa.config relationship - Clarify you only need fossa.config if config is elsewhere Tests (test-parse-fossa-params.sh): - Remove assertion that test should include --branch - Add assertion that test should NOT include --branch (analyze-only) - 18 tests, all passing ✅ Documentation (README.md): - Update fossa.branch commands column to "analyze" only - Add note to fossa.config: "(optional if using fossa.path)" - Add detailed explanation in Special Parameters section - Example: fossa.path=sam-bedrock-agent automatically uses sam-bedrock-agent/.fossa.yml **Key Insight:** If you specify `fossa.path=sam-bedrock-agent`, you don't need to also specify `fossa.config=sam-bedrock-agent/.fossa.yml` because FOSSA automatically looks for .fossa.yml in the working directory. **Before:** ```bash fossa test --branch PR # ❌ Invalid - branch not supported by test ``` **After:** ```bash fossa test --revision abc123 --project MyProject # ✅ Valid ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

shooshmand-sol

👍

johnvincentcorpuz and others added 12 commits December 22, 2025 11:19

fix: Use branch reference for fossa-scan during testing

0c5009b

Use @specify_fossa_config_path branch reference to test changes. This will be changed back to @main before merging. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

johnvincentcorpuz changed the title ~~feat: Add support for custom FOSSA config and path parameters~~ feat(DATAGO-115000): Generic Support for fossa cli flags, implemented path and config here. Dec 22, 2025

johnvincentcorpuz changed the title ~~feat(DATAGO-115000): Generic Support for fossa cli flags, implemented path and config here.~~ feat(DATAGO-115000): Generic Support for fossa cli flags. Implemented path and config here. Dec 22, 2025

shooshmand-sol approved these changes Dec 22, 2025

View reviewed changes

ci: put now with main branch

b6a9615

johnvincentcorpuz merged commit edfccd3 into main Dec 22, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(DATAGO-115000): Generic Support for fossa cli flags. Implemented path and config here. #58

feat(DATAGO-115000): Generic Support for fossa cli flags. Implemented path and config here. #58

Uh oh!

johnvincentcorpuz commented Dec 22, 2025 •

edited

Loading

Uh oh!

shooshmand-sol left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

feat(DATAGO-115000): Generic Support for fossa cli flags. Implemented path and config here. #58

feat(DATAGO-115000): Generic Support for fossa cli flags. Implemented path and config here. #58

Uh oh!

Conversation

johnvincentcorpuz commented Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Key Features

✨ New Parameters

🏗️ Architecture Improvements

Changes

New Files

Modified Files

Problem Solved

Usage Example

Benefits

For Users

For Maintainers

Adding New Parameters

Test Results

Test Plan

Related

Uh oh!

shooshmand-sol left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

johnvincentcorpuz commented Dec 22, 2025 •

edited

Loading