Accepted
Relates to:
The user’s build pipeline includes scanning and linting tasks that operate on the source code and the built image (SAST, antivirus, clair, etc..). The purpose of these tasks is to find problems in the user’s source code or dependencies and alert the user so they can take action (STONE-459).
One frustration we’ve heard from users in previous systems is that they don’t want to be blocked in their development or testing by complications in the build system, by compliance concerns. We want to fix that by offering a system that permits as much progress in the lifecycle of the user’s application (build, test, and pre-production deployment) but which also protects production from non-compliant builds via mechanisms in the enterprise contract.
A problem we face: in Tekton, a failing TaskRun causes the whole PipelineRun to fail. If the purpose of our linting and scanning tasks is to find problems - which usually looks like failure with a non-zero exit code - how do they do their job without constantly breaking the user’s build, stopping them from running integration tests, and stopping them from deploying candidate builds to their lower Environments?
All scanning and linting TaskRuns should succeed even if they find problems in the content they are evaluating.
Use the TEST_OUTPUT result convention from ADR-0030 to expose those results and render them
for users (STONE-459).