The MR closing #345004 introduced a bug that writes the scanner artefact into an unexpected path
The solution to #345004 (closed) introduced a bug that allows the scan artefact to end up in an unexpected path.
The requirement was to write the artefact into the target directory set via the command line switch or the env variable.
see: #345004 (closed)
The variable target
used in the run.go to set the path where the artefact is to be written is not always the target that is set via
cli.flags or the env variables.
Tho following snippet overwrites the target
variable if cfg.AnalyzeAll
is false with matchPath
which can be any of the subdirectories.
The result is that in that case the scan artefact will end up in an unexpected path.
var target string
if cfg.AnalyzeAll {
// analyze the root directory
log.Info("Analyzer will attempt to analyze all projects in the repository")
target = root
} else {
// analyze the directory where there was a match
log.Infof("Analyzer found a supported project at path: %q. Files in this path will be scanned.\n", matchPath)
target, err = filepath.Abs(matchPath)
if err != nil {
return err
}
}
In order to implement the feature request correct the output path for the artefact has to be set to the value of the variable root
.
see: gitlab-org/security-products/analyzers/command!20 (merged) https://gitlab.com/gitlab-org/security-products/analyzers/command/-/blob/4025680fee4d72869bef566e87ee41487c5c9f1d/run.go#L149 https://gitlab.com/gitlab-org/security-products/analyzers/command/-/blob/4025680fee4d72869bef566e87ee41487c5c9f1d/run.go#L132 https://gitlab.com/gitlab-org/security-products/analyzers/command/-/blob/4025680fee4d72869bef566e87ee41487c5c9f1d/run.go#L200
gitlab-org/security-products/analyzers/command!20 (comment 1153546111)