Leverage existing build jobs for SAST and Dependency Scanning
Background:
For several languages (Java, C#, etc.), ~sast and ~"dependency scanning" require to build the project to be able to achieve their operations. Currently, these tools are rebuilding the whole project, even if it was already done previously. It was especially true for Gemnasium since historically the tool didn't have any information about the build process. This is not the case anymore, as the job is part of the same pipeline responsible for building the project, among many other tasks. Supporting all cases to build a project is near to impossible, and leads to a lot of limitations in our implementation.
What questions are you trying to answer?
We want to explore the possibility to leverage previous steps in the pipeline, and rely on the users' configuration instead of figuring out how to build their project.
Are you looking to verify an existing hypothesis or uncover new issues you should be exploring?
We'd like to verify our hypothesis about removing this extra erroneous step from ~sast and ~"dependency scanning". We can extend that process to ~"license management" if we succeed.
What is the backstory of this project and how does it impact the approach?
Some customers are complaining about limitations in our build processes.
What do you already know about the areas you are exploring?
- We don't know any pipeline which doesn't build the project before deploying.
- Pipelines can use artifacts to share content between jobs
- Builds have a very large combination of possibilities
What does success look like at the end of the project?
- We can remove the build phase of ~sast and ~"dependency scanning".
- Pipelines are much faster, because we build only once
- We can support more cases, like multi-modules java projects
- Customers are happy again