Allow user override of project and version through blackDuckProperties #54
Conversation
|
@linanqiu you should document the new properties in blackDuckPlugin.properties too. |
|
@jasonwbarnett done! |
|
@JakeMathews can you help look at this PR? |
|
@linanqiu I am a little confused by the use case here. The ScanModule is not intended to be run on remote or virtual repositories. The plugin needs the ability to read and write properties to the Artifacts. When an artifact is pulled from a remote, it's automatically added to the remote-cache. I am confused as to why the remote-cache is not an option. Also I would advise against using the signature scanner on a remote-cache of open source components due to the quantity. The InspectionModule is what should be used for remote-cache repositories. The InspectionModule should support CRAN. Since there already exists a mechanism for overriding the project name and version, I am hesitating to add this complication. |
Use case: when we scan a directory of packages, the default ends up creating a single version for each component (which results in far too many components). We are scanning a remote repository, so we don't have the option of setting repo level properties -- Artifactory only allows users to set properties on the remote cache, not the remote repo itself (which is the first point of contact for downloads, hence resulting in the remote cache repo's properties not being read) or virtual repos.
This allows users to just set
in the blackDuckPlugin.properties file and have those apply to all scans.
Why we're scanning remote repos: long story, but blackduck doesn't support R libraries out of the box. We have an ongoing thread with a rep from Synopsys, but it doesn't look like this functionality is supported fully. Fortunately, R packages are mostly .tar.gz wrappers around c++ / javascript / fortran libraries, so it's sufficient to just scan those .tar.gz packages. Hence we're scanning a remote repo.