Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds FOSSA CLI configuration file #70137

Merged
merged 4 commits into from
Jul 2, 2020
Merged

Conversation

tylersmalley
Copy link
Contributor

@tylersmalley tylersmalley commented Jun 26, 2020

FOSSA analysis by default checks for dependencies in the following order:

  1. Parse output from npm ls --json --production - Runs if npm exists on the system and provides an accurate list of all dependencies needed to build the production project.
  2. Parse package.json - Runs if package.json can be successfully parsed into a dependency graph.
  3. Run yarn list --json - This command verifies through yarn what the actual dependencies which are installed on the system are. This strategy runs with NODE_ENV=production by default to find production dependencies.
  4. Parse yarn.lock - Detects dependencies based on the yarn lockfile.
  5. Parse npm-shrinkwrap.json - Detects dependencies based on the lockfile.
  6. Parse package-lock.json - Detects dependencies based on the lockfile.

Since our dependencies specified in package.json use compatible version matching (^), the reported version would often not be what the yarn.lock is currently specified to use. Because of this, we are defining a single module with a strategy on yarn.lock. Our yarn.lock file includes all dependencies.

Tyler Smalley added 2 commits June 26, 2020 15:10
Signed-off-by: Tyler Smalley <[email protected]>
Signed-off-by: Tyler Smalley <[email protected]>
@tylersmalley tylersmalley added Team:Operations Team label for Operations Team v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.9.0 labels Jun 26, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-operations (Team:Operations)

@tylersmalley
Copy link
Contributor Author

@elasticmachine merge upstream

@tylersmalley
Copy link
Contributor Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Build metrics

✅ unchanged

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@tylersmalley tylersmalley merged commit 0b6674e into elastic:master Jul 2, 2020
tylersmalley pushed a commit to tylersmalley/kibana that referenced this pull request Jul 2, 2020
FOSSA analysis by default checks for dependencies in the following order:

1. Parse output from `npm ls --json --production` - Runs if npm exists on the system and provides an accurate list of all dependencies needed to build the production project.
2. Parse `package.json` - Runs if `package.json` can be successfully parsed into a dependency graph.
3. Run yarn list --json - This command verifies through yarn what the actual dependencies which are installed on the system are. This strategy runs with `NODE_ENV=production` by default to find production dependencies.
4. Parse `yarn.lock` - Detects dependencies based on the yarn lockfile.
5. Parse `npm-shrinkwrap.json` - Detects dependencies based on the lockfile.
6. Parse `package-lock.json` - Detects dependencies based on the lockfile.

Since our dependencies specified in `package.json` use compatible version matching (`^`), the reported version would often not be what the `yarn.lock` is currently specified to use. Because of this, we are defining a single module with a strategy on `yarn.lock`. Our `yarn.lock` file includes all dependencies.

Signed-off-by: Tyler Smalley <[email protected]>
tylersmalley pushed a commit that referenced this pull request Jul 2, 2020
FOSSA analysis by default checks for dependencies in the following order:

1. Parse output from `npm ls --json --production` - Runs if npm exists on the system and provides an accurate list of all dependencies needed to build the production project.
2. Parse `package.json` - Runs if `package.json` can be successfully parsed into a dependency graph.
3. Run yarn list --json - This command verifies through yarn what the actual dependencies which are installed on the system are. This strategy runs with `NODE_ENV=production` by default to find production dependencies.
4. Parse `yarn.lock` - Detects dependencies based on the yarn lockfile.
5. Parse `npm-shrinkwrap.json` - Detects dependencies based on the lockfile.
6. Parse `package-lock.json` - Detects dependencies based on the lockfile.

Since our dependencies specified in `package.json` use compatible version matching (`^`), the reported version would often not be what the `yarn.lock` is currently specified to use. Because of this, we are defining a single module with a strategy on `yarn.lock`. Our `yarn.lock` file includes all dependencies.

Signed-off-by: Tyler Smalley <[email protected]>

Co-authored-by: Elastic Machine <[email protected]>
tylersmalley pushed a commit to tylersmalley/kibana that referenced this pull request Aug 18, 2020
FOSSA analysis by default checks for dependencies in the following order:

1. Parse output from `npm ls --json --production` - Runs if npm exists on the system and provides an accurate list of all dependencies needed to build the production project.
2. Parse `package.json` - Runs if `package.json` can be successfully parsed into a dependency graph.
3. Run yarn list --json - This command verifies through yarn what the actual dependencies which are installed on the system are. This strategy runs with `NODE_ENV=production` by default to find production dependencies.
4. Parse `yarn.lock` - Detects dependencies based on the yarn lockfile.
5. Parse `npm-shrinkwrap.json` - Detects dependencies based on the lockfile.
6. Parse `package-lock.json` - Detects dependencies based on the lockfile.

Since our dependencies specified in `package.json` use compatible version matching (`^`), the reported version would often not be what the `yarn.lock` is currently specified to use. Because of this, we are defining a single module with a strategy on `yarn.lock`. Our `yarn.lock` file includes all dependencies.

Signed-off-by: Tyler Smalley <[email protected]>
tylersmalley pushed a commit to tylersmalley/kibana that referenced this pull request Aug 18, 2020
FOSSA analysis by default checks for dependencies in the following order:

1. Parse output from `npm ls --json --production` - Runs if npm exists on the system and provides an accurate list of all dependencies needed to build the production project.
2. Parse `package.json` - Runs if `package.json` can be successfully parsed into a dependency graph.
3. Run yarn list --json - This command verifies through yarn what the actual dependencies which are installed on the system are. This strategy runs with `NODE_ENV=production` by default to find production dependencies.
4. Parse `yarn.lock` - Detects dependencies based on the yarn lockfile.
5. Parse `npm-shrinkwrap.json` - Detects dependencies based on the lockfile.
6. Parse `package-lock.json` - Detects dependencies based on the lockfile.

Since our dependencies specified in `package.json` use compatible version matching (`^`), the reported version would often not be what the `yarn.lock` is currently specified to use. Because of this, we are defining a single module with a strategy on `yarn.lock`. Our `yarn.lock` file includes all dependencies.

Signed-off-by: Tyler Smalley <[email protected]>
tylersmalley pushed a commit that referenced this pull request Aug 18, 2020
FOSSA analysis by default checks for dependencies in the following order:

1. Parse output from `npm ls --json --production` - Runs if npm exists on the system and provides an accurate list of all dependencies needed to build the production project.
2. Parse `package.json` - Runs if `package.json` can be successfully parsed into a dependency graph.
3. Run yarn list --json - This command verifies through yarn what the actual dependencies which are installed on the system are. This strategy runs with `NODE_ENV=production` by default to find production dependencies.
4. Parse `yarn.lock` - Detects dependencies based on the yarn lockfile.
5. Parse `npm-shrinkwrap.json` - Detects dependencies based on the lockfile.
6. Parse `package-lock.json` - Detects dependencies based on the lockfile.

Since our dependencies specified in `package.json` use compatible version matching (`^`), the reported version would often not be what the `yarn.lock` is currently specified to use. Because of this, we are defining a single module with a strategy on `yarn.lock`. Our `yarn.lock` file includes all dependencies.

Signed-off-by: Tyler Smalley <[email protected]>
tylersmalley pushed a commit that referenced this pull request Aug 18, 2020
FOSSA analysis by default checks for dependencies in the following order:

1. Parse output from `npm ls --json --production` - Runs if npm exists on the system and provides an accurate list of all dependencies needed to build the production project.
2. Parse `package.json` - Runs if `package.json` can be successfully parsed into a dependency graph.
3. Run yarn list --json - This command verifies through yarn what the actual dependencies which are installed on the system are. This strategy runs with `NODE_ENV=production` by default to find production dependencies.
4. Parse `yarn.lock` - Detects dependencies based on the yarn lockfile.
5. Parse `npm-shrinkwrap.json` - Detects dependencies based on the lockfile.
6. Parse `package-lock.json` - Detects dependencies based on the lockfile.

Since our dependencies specified in `package.json` use compatible version matching (`^`), the reported version would often not be what the `yarn.lock` is currently specified to use. Because of this, we are defining a single module with a strategy on `yarn.lock`. Our `yarn.lock` file includes all dependencies.

Signed-off-by: Tyler Smalley <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:skip Skip the PR/issue when compiling release notes Team:Operations Team label for Operations Team v7.9.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants