-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
chore: run snyk when package.json has changed or base is master #4285
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@ticean, I'd like your thoughts on this before merging
Dockerfile
Outdated
# We use it to determine the base branch of a PR so we can run diffs to conditionally run circle workflows | ||
RUN curl -L "https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64" -o /home/node/jq | ||
RUN chmod +x /home/node/jq | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about removing the jq
addition in project Dockerfile? Doesn't look like it's required. The CI script is running in the CircleCI build environment - there's no docker run ...
in the command.
Unless you found otherwise, the script will run using the circleci/node:8-stretch
image, as inherited from the default config. It already contains jq
. You can verify that with
docker pull circleci/node:8-stretch
docker run --rm circleci/node:8-stretch jq -h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not check to see if jq was in circleci/node:8-stretch
if that's the case, then we shouldn't need to install jq
here. I'll remove it.
Summary
Snyk flags packages that have security vulnerabilities. Our process for resolving these dependencies involves a number of potential resolution steps: updating dependency versions, creating PRs to resolve security issues within dependencies, creating issues to notify package owners of potential security issues, and sometimes ignoring the issue if nothing can be done to resolve the issue at the time.
When we ignore an issue, we set a expiration date on the ignore that will require us to address the issue again when the ignore has expired.
Once an ignore expires, every PR in that repository will fail until the snyk issue has been resolved. This is undesirable because we would rather deal with snyk failures where they are introduced in the case of a PR adding a new dependency with a vulnerability, or in a separate PR to a release branch when the snyk failure is caused by the expiration of an ignore.
This PR adjusts the CircleCI config file to run snyk tests conditionally.
master
branch, snyk should run.Docker
This PR installs a new binary jq into the
meteor-dev
stage of our Dockerfile.jq
makes it simple to work with JSON formatted data within a Unix shell environment. I'm using it to determine the base branch of a PR so that we can accurately determine whether a given PR has made changes topackage.json
Testing
I've made a few commits in this PR that should demonstrate that this circle config is correctly determining the base/target branch of a PR and that the bash script to conditionally run snyk is working correctly. You could also copy this code into your own branch and push it to github to trigger a CI process and see if it's running snyk in the proper circumstances. I've also
ssh
ed into a running CI instance to ensure thatjq
is correctly installed and set up and that the script correctly identifies the PR number and base/target branch for a PR.Other testing is welcomed, though I'm unsure how else to best test a PR like this.