Conversation
Adds a single root FOSSA scan (no matrix -- one repo, one FOSSA project, one manifest row) plus a manifest write guarded to push-on-default-branch, so pull request runs scan without writing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…p ci] This repo publishes an artifact on push to its default branch, so merging the onboarding change would also cut a release. Adding workflow_dispatch means the merge can carry a skip-ci commit -- which suppresses every workflow on that push, the publish one included -- and the scan plus manifest write can then be run by hand against the default branch. The update_manifest guard previously required github.event_name == 'push', so a dispatched run would have scanned and silently skipped the write. It now accepts either event while keeping the default-branch check, so dispatching against any other ref still scans without writing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
AmanRiat1
changed the title
| sca_scan: | ||
| uses: SolaceDev/solace-public-workflows/.github/workflows/sca-scan-and-guard.yaml@main | ||
| with: | ||
| setup_actions: '["setup-node"]' |
There was a problem hiding this comment.
| setup_actions: '["setup-node"]' | |
| setup_actions: '["setup-node"]' | |
| node_version: "24" |
There was a problem hiding this comment.
| # commit (which suppresses every workflow on that push, including the | ||
| # release/publish one) and then have the scan and manifest write triggered | ||
| # by hand. The default-branch check still applies, so dispatching against | ||
| # any other ref scans without writing. |
There was a problem hiding this comment.
Please simplify comment, for example like this:
# Update the manifest only on master-branch pushes or manual runs, never PRs.
# Manual runs allow scanning and updating after [skip ci] without releasing.
| packages: read | ||
| steps: | ||
| - name: Configure AWS credentials | ||
| uses: aws-actions/configure-aws-credentials@7474bc4690e29a8392af63c5b98e7449536d5c3a # v4 |
There was a problem hiding this comment.
| uses: aws-actions/configure-aws-credentials@7474bc4690e29a8392af63c5b98e7449536d5c3a # v4 | |
| uses: aws-actions/configure-aws-credentials@v6 |
| - name: Configure AWS credentials | ||
| uses: aws-actions/configure-aws-credentials@7474bc4690e29a8392af63c5b98e7449536d5c3a # v4 | ||
| with: | ||
| role-to-assume: ${{ secrets.MANIFEST_AWS_ROLE }} |
There was a problem hiding this comment.
Is the secret MANIFEST_AWS_ROLE in the repository settings?
|
|
||
| jobs: | ||
| sca_scan: | ||
| uses: SolaceDev/solace-public-workflows/.github/workflows/sca-scan-and-guard.yaml@main |
There was a problem hiding this comment.
There are two failures: FOSSA Vulnerability Check and FOSSA Policy/Licensing Check
We cannot access the SCA Scan Results mentioned here:
https://github.com/solacecommunity/angular-solace-message-client/actions/runs/33565503264
Can you login and see the problems?
Out maintainer team also needs access so that we can fix any potential vulnerabilities and violations. Can you authorize us?
There was a problem hiding this comment.
Please, squash both commits into a single one according to the Contributing guidelines. Commit message:
ci: add FOSSA SCA scanning and dependency manifest registration
| - "./.git" | ||
| - "./.github" | ||
|
|
||
| paths: |
There was a problem hiding this comment.
Can you please ensure that only path dist/@solace-community is scanned? This is the effective lib which is pushed in npm. The test project should not be scanned and should not report any false positives, since it is not used in any production code.
|
Hi @AmanRiat1, Thanks for your contribution and the PR! Could you review and apply my suggestion? If you have any questions, please let me know. Cheers, |
2 participants
Adds FOSSA SCA scanning on
masterplus a build-manifest registration step, so this repo is covered by our automated dependency vulnerability tracking.What this adds
.fossa.yml.github/workflow-config.jsonREPORTmode — this gates nothing.github/workflows/sca-scan-and-guard.ymlmaster; manifest write on push onlyNon-blocking by design
REPORTmode means FOSSA findings are recorded, not enforced. This PR cannot start failing anyone else's builds.The
update_manifestjob is guarded ongithub.event_name == 'push' && github.ref_name == github.event.repository.default_branch, so it does not run on pull requests — only the scan does.Pattern notes
Mirrors the equivalent setup already merged and passing across our other public repos. One thing carried over deliberately: no scan matrix.
fossa.only_pathscopes what is scanned, but the project id comes from--project, so matrix entries all upload into one project and overwrite each other, while the manifest emits one row per entry — producing registrations that point at FOSSA projects which never exist. A root scan resolves every ecosystem in one pass. One repo, one FOSSA project, one manifest row.