You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+46Lines changed: 46 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,49 @@
1
1
# Contributing
2
2
3
+
## Development
4
+
### Setup
5
+
Run `npm run build` in the root folder. All tooling prerequisites (Node.js, TypeScript etc.) can be seen [here](https://docs.microsoft.com/en-us/azure/devops/extend/develop/add-build-task?view=azure-devops#prerequisites) and should be installed.
6
+
7
+
### Test and Run
8
+
Unit tests can be run via `npm run test:unit` command.
9
+
10
+
To run the code, a GitHub PR against `develop` should be raised with the committed code to the branch PR. The PR runs deployment script with deploy to development environment. The script builds the code that's added as part of your change and installs it in Azure DevOps organization as an extension that can be added to run a pipeline.
11
+
12
+
### Local debugging
13
+
14
+
A number of environment variable are required for debugging, here's an example launch config for `VSCode` that sets mandatory parameters such as `AGENT_TEMPDIRECTORY`, `INPUT_failOnIssues` and `INPUT_authToken`
The release process is fully-automated: all you need to do is create a PR to merge `develop` into `master` and call the PR `Merge develop into master for release`.
46
+
3
47
## Contributor Agreement
4
48
A pull-request will only be considered for merging into the upstream codebase after you have signed our [contributor agreement](https://github.com/snyk/snyk-azure-pipelines-task/blob/master/Contributor-Agreement.md), assigning us the rights to the contributed code and granting you a license to use it in return. If you submit a pull request, you will be prompted to review and sign the agreement with one click (we use [CLA assistant](https://cla-assistant.io/)).
5
49
@@ -36,6 +80,8 @@ To release a major you need to add `BREAKING CHANGE: ` to the start of the body
36
80
37
81
Ensure that your code adheres to the included `.eslintrc` config by running `npm run test:checks`.
38
82
83
+
Fix any `prettier` violations reported before pushing by running `npm run format`
84
+
39
85
## Sending pull requests
40
86
41
87
- add tests for newly added code (and try to mirror directory and file structure if possible) or fixes
| serviceConnectionEndpoint | The Azure DevOps service connection endpoint where your Snyk API token is defined. Define this within your Azure DevOps project settings / S | no | none | String / Azure Service Connection Endpoint of type SnykAuth / Snyk Authentication |
25
-
| testType | Used by the task UI only | no | "application" | string: "app" or "container" |
26
-
| dockerImageName | The name of the container image to test. | yes, if container image test | none | string |
27
-
| dockerfilePath | The path to the Dockerfile corresponding to the `dockerImageName`| yes, if container image test | none | string |
28
-
| targetFile | Applicable to application type tests ony. The path to the manifest file to be used by Snyk. Should only be provided if non-standard. | no | none | string |
29
-
| severityThreshold | The severity-threshold to use when testing. By default, issues of all severity types will be found. | no | "low" | string: "low" or "medium" or "high" or "critical" |
30
-
| monitorWhen | When to run `snyk monitor`. Valid options are `always` (default), `noIssuesFound`, and `never`. If set, this option overrides the value of `monitorOnBuild`. | no | "always" | boolean |
31
-
| failOnIssues | This specifies if builds should be failed or continued based on issues found by Snyk. | yes | true | boolean |
32
-
| projectName | A custom name for the Snyk project to be created on snyk.io | no | none | string |
33
-
| organization | Name of the Snyk organisation name, under which this project should be tested and monitored | no | none | string |
34
-
| testDirectory | Alternate working directory. For example, if you want to test a manifest file in a directory other than the root of your repo, you would put in relative path to that directory. | no | none | string |
35
-
| ignoreUnknownCA | Use to ignore unknown or self-signed certificates. This might be useful in for self-hosted build agents with unusual network configurations or for Snyk on-prem installs configured with a self-signed certificate. | no | false | boolean |
36
-
| additionalArguments | Additional Snyk CLI arguments to be passed in. Refer to the Snyk CLI help page for information on additional arguments. | no | none | string |
| serviceConnectionEndpoint | The Azure DevOps service connection endpoint where your Snyk API token is defined. Define this within your Azure DevOps project settings / S | no | none | String / Azure Service Connection Endpoint of type SnykAuth / Snyk Authentication |
25
+
| testType | Used by the task UI only | no | "application" | string: "app" or "container" |
26
+
| dockerImageName | The name of the container image to test. | yes, if container image test | none | string |
27
+
| dockerfilePath | The path to the Dockerfile corresponding to the `dockerImageName`| yes, if container image test | none | string |
28
+
| targetFile | Applicable to application type tests ony. The path to the manifest file to be used by Snyk. Should only be provided if non-standard. | no | none | string |
29
+
| severityThreshold | The severity-threshold to use when testing and reporting. By default, issues of all severity types will be found. | no | "low" | string: "low" or "medium" or "high" or "critical" |
30
+
| failOnThreshold | The `severityThreshold` parameter is used to control the interaction with the Snyk CLI and reporting vulnerabilities. The `failOnThreshold` gives you additional control over build failure behaviour. For example, with `failOnIssues` set to `true` and `failOnThreshold` to `critical`, all issues would be reported on but _only_ critical issues would cause a build failure. See Usage Examples for more information | no | "low" | string: "low" or "medium" or "high" or "critical" |
31
+
| monitorWhen | When to run `snyk monitor`. Valid options are `always` (default), `noIssuesFound`, and `never`. If set, this option overrides the value of `monitorOnBuild`. | no | "always" | boolean |
32
+
| failOnIssues | This specifies if builds should be failed or continued based on issues found by Snyk. Combine with `failOnThreshold` to control which severity of issues causes the build to fail | yes | true | boolean |
33
+
| projectName | A custom name for the Snyk project to be created on snyk.io | no | none | string |
34
+
| organization | Name of the Snyk organisation name, under which this project should be tested and monitored | no | none | string |
35
+
| testDirectory | Alternate working directory. For example, if you want to test a manifest file in a directory other than the root of your repo, you would put in relative path to that directory. | no | none | string |
36
+
| ignoreUnknownCA | Use to ignore unknown or self-signed certificates. This might be useful in for self-hosted build agents with unusual network configurations or for Snyk on-prem installs configured with a self-signed certificate. | no | false | boolean |
37
+
| additionalArguments | Additional Snyk CLI arguments to be passed in. Refer to the Snyk CLI help page for information on additional arguments. | no | none | string |
37
38
38
39
## Usage Examples
39
40
@@ -66,6 +67,19 @@ Here's a full example:
66
67
monitorWhen: 'always'
67
68
```
68
69
70
+
An example that specifies a value for `severityThreshold` as medium and configures `failOnThreshold` to critical. This configuration would _only fail_ the build when critical issues are found, but all issues detected at medium, high and critical would be reported back to your snyk project for analysis
0 commit comments