ensure sbom dir is empty #106
Conversation
| @@ -295,7 +295,8 @@ find_blob_url() { | |||
| end' < "$attestation_file" | |||
| } | |||
|
|
|||
| echo "Making sure $SBOMS_DIR directory exists" | |||
| echo "Making sure $SBOMS_DIR directory exists and is empty prior to downloading" | |||
| rm -rf "$SBOMS_DIR" | |||
There was a problem hiding this comment.
This looks scary for running the script locally. A dev can have the SBOMS_DIR set to something that they wouldn't want rm -rfed
The init.sh file is not run as part of the gitops pipeline so the SBOM dir was not being reset.
Should we just run the init.sh file for the gitops pipeline?
There was a problem hiding this comment.
Yes, if its set wrong (currently env.sh sets to export SBOMS_DIR=results/sboms) and for gitlab to work, its needed to be in results because the results directory gets copied between job steps
When run locally, the directory will be in tmp/reponame/results but if a user sets to ~/save-forever-files then yeah :(
Re: add back the init... Yes. the init script already does an rm -rf results and then checks for all those extra ENV vars for the build pipeline which are extra for the gitops one.
Given we know the env vars for in the pipelines via data.yaml we generate the list of mandatory vars similar to how we check in github actions (which currently checks twice) we could probably generate an ENV var like "REQUIRE_ENVS") and then init checks the ones in that variable.
There was a problem hiding this comment.
I think it's okay, though I guess we could do a rm -rf $SBOMS_DIR/*.json or something like that to make it safer. The -o nounset provides some safety here also.
The init.sh file is not run as part of the gitops pipeline so the SBOM dir was not being reset.
This can result in multiple sboms being uploaded if you are using a long running Jenkins.