Should I use publish_results: true in PRs?

[brianjmurrell]

If I use the ossf/scorecard-action in a workflow with triggers:

on:
  schedule:
    - cron: '45 8 * * 0'
  push:
    branches: ["master"]
  pull_request:

do I really want to publish_results: true from pull_request:s?

That is, are results kept separate per branch or is the database really just one entry per project and the last write wins? If so, then is the obvious repercussion that if a PR has published the most recent results and it has new Scorecard issues in it that are not in master, the Scorecoard for the project now has the score of the PR with new Scorecard issues?

If the above is all true, what is the best practices in this case? Separate workflows for pull_request: and push: branches: [master] and/or schedule? Which raises a second, tangential question, if one is publishing on every push to master, does having a schedule: trigger make little (i.e. no) sense?

[spencerschrock]

Just as a disclaimer: the pull_request trigger is experimental as mentioned in the Scorecard Action README.

are results kept separate per branch or is the database really just one entry per project and the last write wins?

one per project (from the default branch), with some history with the optional commit query parameter

do I really want to publish_results: true from pull_request:s?

The action doesn't have access to the id-token permission needed to sign + publish results, so nothing to worry about there.
But we do explicitly check it's not pull_request before publishing.
https://github.com/ossf/scorecard-action/pull/935/files

Which raises a second, tangential question, if one is publishing on every push to master, does having a schedule: trigger make little (i.e. no) sense?

Some checks have a time-based element: Maintained and Vulnerabilities (new vulns may be reported even if the project)