Skip to content

Commit

Permalink
Merge pull request #162 from blackducksoftware/sb_applyDocEdits
Browse files Browse the repository at this point in the history
Sb apply doc edits
  • Loading branch information
stevebillings committed Apr 24, 2020
2 parents 118025f + 5d77a65 commit 7870ce5
Show file tree
Hide file tree
Showing 7 changed files with 42 additions and 41 deletions.
28 changes: 14 additions & 14 deletions docs/templates/content/90-releasenotes.ftl
Expand Up @@ -2,28 +2,28 @@

## Version 6.3.0
### New features
* (IDETECT-1917) The Yarn detector will now extract project information from package.json files.
* (IDETECT-1874) The Yarn Detector supports dependencies that are missing a fuzzy version in a lockfile dependency declaration.
* (IDETECT-1867) ${solution_name} when configured to [fail on policy violations](../properties/configuration/project/#fail-on-policy-violation-severities), will now log policy violations.
* The Yarn detector extracts project information from package.json files.
* Added Yarn Detector support for dependencies that are missing a fuzzy version in a lockfile dependency declaration.
* ${solution_name} logs policy violations when it is configured to [fail on policy violations](../properties/configuration/project/#fail-on-policy-violation-severities).

### Changed features
* (IDETECT-1894) Users are now allowed to [upload source](../properties/configuration/signature scanner/#upload-source-mode) when only [license search](../properties/configuration/signature scanner/#signature-scanner-license-search) is provided.
* (IDETECT-1853) ${solution_name} is now compatible with Yocto 3.0.
* (IDETECT-1876) ${solution_name} will stop if docker is enabled on Windows.
* (IDETECT-1961) ${solution_name} now configures Docker Inspector's working directories to inside ${solution_name}'s run directory.
* ${solution_name} now runs (and requires) Docker Inspector version 9.
* Users can [upload source](../properties/configuration/signature scanner/#upload-source-mode) files when only [license search](../properties/configuration/signature scanner/#signature-scanner-license-search) is enabled.
* ${solution_name} is now compatible with Yocto 3.0.
* ${solution_name} stops if the Docker Inspector tool applies and ${solution_name} is running on Windows.
* ${solution_name} configures Docker Inspector's working directories inside ${solution_name}'s run directory.
* ${solution_name} requires and runs Docker Inspector version 9.

### Resolved issues
* (IDETECT-1906) Resolved an issue where git extraction could fail if "git log" returned unexpected output. The commit hash will be used as a version as a last resort. ([\#114](https://github.com/blackducksoftware/synopsys-detect/issues/114))
* (IDETECT-1883) Resolved an issue where ${solution_name} would fail to extract project information while parsing a Git repository with a detached head while in buildless mode.
* (IDETECT-1970) Resolved an issue where the default value for [parallel processors](../properties/configuration/general/#detect-parallel-processors-advanced) was not honored. (The available runtime processor count was being used instead.)
* (IDETECT-1906) Resolved an issue wherein git extraction might fail if "git log" returned unexpected output. As a last resort, the commit hash will be used as a version. ([\#114](https://github.com/blackducksoftware/synopsys-detect/issues/114))
* (IDETECT-1883) Resolved an issue where ${solution_name} failed to extract project information when parsing a Git repository with a detached head while in buildless mode.
* (IDETECT-1970) Resolved an issue where the default value for [parallel processors](../properties/configuration/general/#detect-parallel-processors-advanced) was not used. The available runtime processor count was being used instead.
* (IDETECT-1973) Resolved an issue where the Nuget exe inspector would not resolve from Artifactory.
* (IDETECT-1965) Resolved an issue where ${solution_name} would fail to resolve environment variables where it previously would.
* (IDETECT-1974) The Yarn detector will no longer throw an exception for dependencies not defined in the yarn.lock.
* (IDETECT-1965) Resolved an issue where ${solution_name} would fail to resolve environment variables where it did so previously.
* (IDETECT-1974) Resolved an issue wherein the Yarn detector was throwing an exception for dependencies not defined in the yarn.lock file.

## Version 6.2.1
### Resolved issues
* Fixed an issue where an exception would be thrown when generating a risk report if the user did not set the risk report output path explicitly. (IDETECT-1960)
* Resolved an issue wherein an exception was thrown when generating a risk report if users didn't set the risk report output path explicitly. (IDETECT-1960)

## Version 6.2.0
### New features
Expand Down
4 changes: 2 additions & 2 deletions docs/templates/content/advanced/BD-user-role-requirements.ftl
Expand Up @@ -8,5 +8,5 @@ Overview:

Additional details:

* The Project Code Scanner role is insufficient to run any ${solution_name} post build actions; for example, policy check, notices report, risk report.
* A user with the Global Code Scanner role can (as of ${blackduck_product_name} 2019.6) generate a report, but cannot delete the report when it's complete. The BOM Manager role is required for the delete.
* The Project Code Scanner role is insufficient to run any ${solution_name} post-build actions; for example, policy check, notices report, or risk report.
* A user with the Global Code Scanner role can (as of ${blackduck_product_name} 2019.6) generate a report, but cannot delete the report. The BOM Manager role is required to delete the report.
Expand Up @@ -34,7 +34,7 @@ If you are interested in components from the application layers of your image, b

For example, if you build your application on ubuntu:latest (your Dockerfile starts with FROM ubuntu:latest), you can exclude components from the Ubuntu layer(s) so that the components generated by ${solution_name} using Docker Inspector and the ${blackduck_signature_scanner_name} contain only components from your application layers.

First, find the layer ID of the platform's top layer. To do this:
First, find the layer ID of the platform's top layer. To do this task:

Run the docker inspect command on the base image; in our example this is ubuntu:latest.
Find the last element in the RootFS.Layers array. This is the platform top layer ID. In the following example, this is sha256:b079b3fa8d1b4b30a71a6e81763ed3da1327abaf0680ed3ed9f00ad1d5de5e7c.
Expand Down
@@ -1,44 +1,44 @@
# Npm support
# npm support

${solution_name} has three detectors for Npm:
${solution_name} has the following npm detectors:

* Npm Package Lock detector
* Npm Package Shrinkwrap detector
* Npm Package Json detector
* Npm Cli detector
* npm package lock detector
* npm package shrinkwrap detector
* npm package JSON detector
* npm CLI detector

## Npm Package Lock
## npm package lock

The Npm Package Lock is the preferred Npm detector and runs when it finds a [package-lock.json](https://docs.npmjs.com/configuring-npm/package-lock-json.html) generated by Npm.
The npm package lock is the preferred npm detector and runs when it finds a [package-lock.json](https://docs.npmjs.com/configuring-npm/package-lock-json.html) generated by npm.

Npm automatically generates the package-lock.json after an "npm install" which should be run prior to scanning.
npm automatically generates the package-lock.json after an "npm install" which should be run prior to scanning.

This is the most accurate way ${solution_name} supports Npm as lock file contains resolved versions and all transitives.
This is the most accurate way ${solution_name} supports npm as lock file contains resolved versions and all transitives.

## Npm Shrinkwrap
## npm shrinkwrap

The Npm Shrinkwrap detector uses the [npm-shrinkwrap.json](https://docs.npmjs.com/files/shrinkwrap.json) file.
The npm shrinkwrap detector uses the [npm-shrinkwrap.json](https://docs.npmjs.com/files/shrinkwrap.json) file.

It is the same as a package-lock.json but is supposed to publishable. ${solution_name} always chooses Shrinkwrap over Package Lock.
It is the same as a package-lock.json but is a publishable lockfile. ${solution_name} always chooses shrinkwrap over package lock.

## Npm Cli Detector
## npm detector

The Npm Cli detector requires a package.json and an Npm executable.
The npm CLI detector requires a package.json and an npm executable.

It will execute "npm -ls json" and parse the dependencies reported by the npm cli.
It executes "npm -ls json" and parses the dependencies reported by the npm CLI.

It requires that the Npm command succeeds - does not write to ERR and returns exit code 0.

If your Npm command does not, you can silence the errors by adding the --silent npm argument using --detect.npm.arguments.
If your npm command does not, you can silence the errors by adding the --silent npm argument using --detect.npm.arguments.

This detector is only invoked if the other detectors are not invoked and generating lockfiles for the other detectors should be preferred.

## Npm Package Json
## npm package JSON

The Npm Cli detector is the fallback when in Build mode. When in buildless the fall back detector is Npm Package Json.
The npm CLI detector is the fallback when in Build mode. When in buildless the fallback detector is npm package JSON.

This is the least accurate of the Npm detectors.
This is the least accurate of the npm detectors.

It requires and parses a "package.json".

It will not find transitives and will only report the wild-card version present in file.
It does not find transitives and only reports the wild-card version present in the file.
Expand Up @@ -18,7 +18,8 @@ You can use the following property to customize the timestamp format:
## Project and version naming for Git projects

If no package manager provides project and version names, you have not provided the project and version names through properties, and the project uses Git, ${solution_name} attempts to use Git to determine project information.
Project information is extracted from the remote URL for the current branch. The version is the current branch name, or the commit hash if a detached head is checked out. This is performed by the Git detector. If you do not want ${solution_name} to use Git data, you can omit the Git detector using the following property:

Project information is extracted from the remote URL for the current branch. The version is the current branch name, or the commit hash if a detached head is checked out. This is done by the Git detector. If you don't want ${solution_name} to use Git data, omit the Git detector using the following property:
```
--detect.excluded.detector.types=GIT
```
Expand Down
Expand Up @@ -38,7 +38,7 @@ Diagnostic mode:
* vendor.config.
* C/C++ compilation database.

The option -de allows the collection of relevant files not generated by ${solution_name}; for example, lock files. By default, diagnostic mode only include files generated by ${solution_name} where -de might include files it finds. For example, a package.lock that is too deep for ${solution_name}'s search depth is not included, or a package.lock that was not parsed due to exclusion.
The option -de enables the collection of relevant files that are not generated by ${solution_name}; for example, lock files. By default, diagnostic mode only includes files generated by ${solution_name} where -de might include files it finds. For example, a package.lock that is too deep for ${solution_name}'s search depth is not included, or a package.lock that was not parsed due to exclusion.

After running a scan with diagnostic mode, results similar to the following display in your output.

Expand Down
Expand Up @@ -41,7 +41,7 @@ detect.sh is trying to execute this command:
````
curl --silent --header \"X-Result-Detail: info\" https://sig-repo.synopsys.com/api/storage/bds-integrations-release/com/synopsys/integration/synopsys-detect?properties=DETECT_LATEST
````
The response to this command should be similar to:
The response to this command should be similar to the following:
```
{
"properties" : {
Expand Down

0 comments on commit 7870ce5

Please sign in to comment.