Right now this is an extension to composer and hooking into it.
Running these assertions in CI is not very easy.
So having a dedicated config file or some command to run specific configs during CI would be great.
We rather have such blocking tools decoupled in CI than blocking a developers interest in finding out interesting stuff.
This is currently possible by putting the extra-config in the repo but running composer require ... and composer update in the CI.
But there are multiple scenarios:
Our SAST-CI wants to go for check-abandoned only.
Our Compliance-CI wants to go for plenty other checks.
The Compliance-CI shall fail on check-lock-file but pass with warning for check-description
This makes it 3 different configs.
By now we store different configs as JSON and merge them during CI (jq -s '.[0] * .[1]' composer.json pdg-sast.json | sponge composer.json)
So having different configs is possible but not native by this package.
Here you go. This is what I thought about it yesterday :)
Focus is on a dedicated command for CI and allow the dev to try things.
Right now this is an extension to composer and hooking into it. Running these assertions in CI is not very easy. So having a dedicated config file or some command to run specific configs during CI would be great.
composer require ...
andcomposer update
in the CI.jq -s '.[0] * .[1]' composer.json pdg-sast.json | sponge composer.json
)Here you go. This is what I thought about it yesterday :) Focus is on a dedicated command for CI and allow the dev to try things.