Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
Contributions to this project are released to the public under the project's open source license.
Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
This Action makes an authenticated query to the Dependency Graph Diff
API endpoint (GET /repos/{owner}/{repo}/dependency-graph/compare/{basehead}
)
to find out the set of added and removed dependencies for each manifest.
git clone https://github.com/actions/dependency-review-action.git
cd dependency-review-action
npm install
npm run test
Note: We don't have any useful tests yet, contributions are welcome!
It is recommended to have atleast Node 18 installed.
We have a script to scan a given PR for vulnerabilities, this will
help you test your local changes. Make sure to grab a Personal Access Token (PAT) before proceeding (you'll need repo
permissions for private repos):
The syntax of the script is:
$ GITHUB_TOKEN=<token> ./scripts/scan_pr <pr_url>
Like this:
$ GITHUB_TOKEN=my-secret-token ./scripts/scan_pr https://github.com/actions/dependency-review-action/pull/3
Configuration options can be set by
passing an external YAML configuration file to the
scan_pr
script with the -c
/--config-file
option:
$ GITHUB_TOKEN=<token> ./scripts/scan_pr --config-file my_custom_config.yml <pr_url>
- Fork and clone the repository
- Configure and install the dependencies:
npm install
- Make sure the tests pass on your machine:
npm run test
- Create a new branch:
git checkout -b my-branch-name
- Make your change, add tests, and make sure the tests still pass
- Make sure to build and package before pushing:
npm run build && npm run package
- Push to your fork and submit a pull request
- Pat your self on the back and wait for your pull request to be reviewed and merged.
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
- Add unit tests for new features.
- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
- Write a good commit message.
- Add examples of the usage to examples.md
- Link to a sample PR in a custom repository running your version of the Action.
- Update the version number in package.json.
- Go to Draft a new release in the Releases page.
- Make sure that the
Publish this Action to the GitHub Marketplace
checkbox is enabled
- Click "Choose a tag" and then "Create new tag", where the tag name
will be your version prefixed by a
v
(e.g.v1.2.3
). - Use a version number for the release title (e.g. "1.2.3").
- Add your release notes. If this is a major version make sure to include a small description of the biggest changes in the new version.
- Click "Publish Release".
You now have a tag and release using the semver version you used
above. The last remaining thing to do is to move the dynamic version
identifier to match the current SHA. This allows users to adopt a
major version number (e.g. v1
) in their workflows while
automatically getting all the
minor/patch updates.
To do this just checkout main
, force-create a new annotated tag, and push it:
git tag -fa v4 -m "Updating v4 to 4.0.1"
git push origin v4 --force
We have begun using a Stalebot action to help keep the Issues and Pull requests backlogs tidy. You can see the configuration here. If you'd like to keep an issue open after getting a stalebot warning, simply comment on it and it'll reset the clock.