PHPLIB-1434: Publish SSDLC assets upon release #1342
Conversation
alcaeus
force-pushed
the
phplib-1434-archive-sbom-on-release
branch
from
89aed9b to
bfce118
Compare
alcaeus
force-pushed
the
phplib-1434-archive-sbom-on-release
branch
from
bfce118 to
4b3c5b1
Compare
| @@ -27,6 +31,8 @@ jobs: | |||
| steps: | |||
| - name: "Checkout" | |||
| uses: "actions/checkout@v4" | |||
| with: | |||
| ref: ${{ github.event_name == 'workflow_dispatch' && inputs.ref || github.ref }} | |||
There was a problem hiding this comment.
I wasn't familiar with the syntax, but I consulted the Expressions docs to infer that it's a ternary statement and equivalent to the following:
if (github.event_name == 'workflow_dispatch') {
inputs.ref ?? github.ref
} else {
github.ref
}
| static-analysis: | ||
| needs: prepare-release | ||
| name: "Run Static Analysis" | ||
| uses: ./.github/workflows/static-analysis.yml |
There was a problem hiding this comment.
By default, I assume this would invoke all jobs in the referenced file and that's why you added a conditional on the Rector job.
I noted that this is re-using an entire workflow (jobs.<job_id>.uses), as opposed to an action being imported into a step (jobs.<job_id>.steps[*].uses).
I'm a bit confused about how this single static-analysis job would map to multiple jobs in static-analysis.yml if you hadn't specified a condition to exclude Rector. Would they just be run in sequence? Reusing Workflows doesn't address this, and the example therein only has a single job defined in the import file. To that end, I wonder if it'd make more sense to split the Psalm and Rector jobs into separate files (e.g. static-analysis-psalm.yml and static-analysis-rector.yml) if there isn't much commonality between them anyway.
There was a problem hiding this comment.
Yes - unlike actions that contain a set of functionality to be included in a job, this allows to reuse an entire workflow as a job in a different workflow, without sharing data with any other job.
As for what this looks like, I wasn't sure at first either but it actually looks rather nice: https://github.com/alcaeus/mongo-php-library/actions/runs/9447195881. I'll split the workflow up into separate workflows for psalm and rector.
| uses: mongodb-labs/drivers-github-tools/code-scanning-export@v2 | ||
| with: | ||
| ref: ${{ inputs.version }} | ||
| output-file: ${{ env.S3_ASSETS }}/code-scanning-alerts.json |
There was a problem hiding this comment.
It's not clear to me where env.S3_ASSETS gets set. Does publishing here depend on the "Set up drivers-github-tools" task above, which is configured with the AWS secrets?
There was a problem hiding this comment.
This is set by the setup action above. I'll add a comment for this
| workflow_call: | ||
| inputs: | ||
| ref: | ||
| description: "The git reference to check" |
There was a problem hiding this comment.
Nit: in this case, I think "git ref" is the more readable name, even though it's an abbreviation.
PHPLIB-1434
This PR changes the release workflow to publish all SSDLC assets. Since we need to produce a SARIF export of all code scanning alert, the "Static Analysis" workflow is manually invoked (see docs) instead of being automatically run for tags. This ensures that when we get to the
publish-ssdlc-assetsjob the psalm run will have completed and analysis of the SARIF report uploaded to Code Scanning is done. This couldn't be guaranteed if static analysis was run on the tag directly.In the
publish-ssdlc-assetsjob, we generate the document for authorized publication, download the SBOM file from silk, create a SARIF export of all open code scanning alerts, generate the SSDLC compliance report, and upload the whole thing to our S3 release assets bucket. Merging this pull request will conclude the SSDLC effort in PHPLIB.This PR depends on the following pull requests being merged:
Furthermore, there currently is an issue with Silk that causes the SBOM download to fail. Once that issue is resolved, I can test the workflow again with the SBOM steps enabled. The rest was already tested and confirmed to work.