Currently we have no explicit version control information inside our report model.
With #3093 we will provide revision information for secret scan findings
But some information are missing with #3093
type of scm(source code management)/version control (we will use version control because more generic)
location of version control
revision id of scan
Wanted
It shall be possible to provide relevant version control information inside a job report
Solution
Extend inside meta data. Here an example for the new element syntax:
Thoughts about future scenario of handling multiple version control data
SecHub currently focuses on one repository only. This is the reason why we do not use a an array for version control information here: It is clear that the complete report, every finding is referencing this version control only. And if the finding has no revision set, it will use the revision defined at the meta data section.
If there is any need in future to provide multiple version control definitions, we can still do
introduce optional "name" attribute inside version control data
provide "additionalVersionControl" element inside "metaData"
insist here on "name" attribute set
enhance "revision" data elements with "versionControlName" attribute where the name
is referenced, so it would be clear which version control is meant/referenced
But currently there is no need for such a handling - we keep it as simple as possible for the moment.
Situation
Currently we have no explicit version control information inside our report model. With #3093 we will provide revision information for secret scan findings
But some information are missing with #3093
Wanted
It shall be possible to provide relevant version control information inside a job report
Solution
Extend inside meta data. Here an example for the new element syntax:
Thoughts about future scenario of handling multiple version control data
SecHub
currently focuses on one repository only. This is the reason why we do not use a an array for version control information here: It is clear that the complete report, every finding is referencing this version control only. And if the finding has no revision set, it will use the revision defined at the meta data section.If there is any need in future to provide multiple version control definitions, we can still do
But currently there is no need for such a handling - we keep it as simple as possible for the moment.