ci(.github): add fossa.yml

[vdice]

Adds a workflow to run FOSSA scans for this project (ref CNCF Onboarding (view))

Supersedes #3137 to test workflow from branch on origin.

[vdice]

We had a successful scan earlier (https://github.com/spinframework/spin/actions/runs/15053169359) but noticed the errors parsing a few go templates, so @kate-goldenring and I figured we'd learn up on using the .fossa.yml config to exclude them (eg exclude all templates) but haven't yet hit on an action config that works (we may be running into bug(s) with the upstream action). Anyways, may defer use of Fossa config to a follow-up (the template parsing errors don't prevent an actual fossa scan; report still generated eg https://app.fossa.com/projects/custom%2b162%2fgithub.com%2fspinframework%2fspin/refs/branch/master/5eace0a4d9cdc5b8beee20d6932855412bb2cda4) Will revisit after lunch....

[vdice]

I'm continuing to run into a few issues so have sent an email to fossa support, copying Kate.

[vdice]

Back up for review. Hadn't yet heard back from support. Deferring use of a .fossa.yml config file to #3142.

[vdice]

Lastly, and this can be a follow-up if we'd like to further deliberate, but I think it may be worthwhile to just hard-code the push-only FOSSA_API_KEY into the workflow. FOSSA claims Push-Only tokens can only be used to send data to FOSSA. This allows your CI to safely expose them to 3rd parties. This would allow all PRs (from forks or otherwise) to run the checks, which would be great.

edit: updated/de-secreted

[lann]

Lastly, and this can be a follow-up if we'd like to further deliberate, but I think it may be worthwhile to just hard-code the push-only FOSSA_API_KEY into the workflow. FOSSA claims Push-Only tokens can only be used to send data to FOSSA. This allows your CI to safely expose them to 3rd parties. This would allow all PRs (from forks or otherwise) to run the checks, which would be great.

sgtm; seems pretty common: https://github.com/search?q=%2FFOSSA_API_KEY%3A+%22%3F%5B%5E%24%5D%2F+path%3A%2F%5E.github%2F&type=code

[kate-goldenring]

I am trying to think through how we are supposed to use / interpret these scans. Right now, failures / invalid licenses do not cause the action to fail. Are maintainers supposed to periodically check the results and amend license issues? Are we hopping that once we add the fossa config we can then make failures lead to failed CI?

[vdice]

@kate-goldenring right, I think perhaps we'll want to revisit incorporating the fossa test command -- and most likely something in the form where we check the diff on the current PR/branch revision as mentioned here. I can experiment with this here. I think failing the CI check would be the way to go -- but as a prerequisite we'd want a blank slate and would need to first address the current scan issues. Otherwise, as you mention, the action always succeeds and it would be up to the maintainers to periodically check in -- which isn't ideal.

[vdice]

😭 Needs a full-access (and thus sensitive) API key but then forks won't be able to use it when in the form of a GH secret, negating the main utility for running fossa test. Actually, there are two errors: 1. api key, 2. actual scan errors. I'm not sure if eliminating the actual scan errors will produce a successful run (first error more like a warning) or not.

/opt/hostedtoolcache/fossa/3.10.9/linux_amd64/fossa test 
Using project name: `[https://github.com/spinframework/spin`](https://github.com/spinframework/spin%60)
Using revision: `9c030ebc8e0f154f0f996fcd7e0a53d82badca45`
[ Checking build completion for 9c030ebc8e0f154f0f996fcd7e0a53d82badca45... ]
[ Waiting for build completion (revision 9c030ebc8e0f154f0f996fcd7e0a53d82badca45)... last status: StatusCreated ]
[ Waiting for build completion (revision 9c030ebc8e0f[15](https://github.com/spinframework/spin/actions/runs/15193228107/job/42731004395#step:4:16)4f0f996fcd7e0a53d82badca45)... last status: StatusCreated ]
[ Waiting for build completion (revision 9c030ebc8e0f154f0f996fcd7e0a53d82badca45)... last status: StatusRunning ]
[ Waiting for build completion (revision 9c030ebc8e0f154f0f996fcd7e0a53d82badca45)... last status: StatusRunning ]
[ Waiting for issue scan completion... ]
Error:  A push-only API key was used, so issue details cannot be displayed.
  Check the webapp for issue details, or rerun this command with a full-access API key.
Error:  An issue occurred
  *** Relevant Errors ***
      Error: The scan has revealed issues. Number of issues found: 13

I'm beginning to think for this first phase we just check the FOSSA box by only running fossa analyze (which as mentioned always succeeds and publishes failures to the fossa website) -- and relying on maintainer attention to the scan results in the near-term 🫤. (Maybe add a badge to the README to put a bit more pressure on us?) Or punt again and put back into draft to revisit when I/we have renewed gumption.

I'm not sure if eliminating the actual scan errors will produce a successful run (first error more like a warning) or not.

Maybe it's worth trying to address the scan errors to get to a blank state; I'll look into this in the meantime.