Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
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.
Found a bug?
- Ensure the bug was not already reported by searching on GitHub under Issues.
- If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or a reproducible test case demonstrating the expected behavior that is not occurring.
- If possible, use the relevant bug report templates to create the issue.
What should I know before submitting a pull request or issue
lib/) is subsequently compiled using NCC (found in
dist/) to avoid having to include the
node_modules/ directory in the repository.
Submitting a pull request
- Fork and clone the repository
- Configure and install the dependencies:
- Create a new branch:
git checkout -b my-branch-name
- Make your change, add tests, and make sure the tests still pass:
npm run test
- Make sure your code is correctly formatted:
npm run format
- Push to your fork and submit a pull request
- Pat yourself 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:
- Write tests.
- 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.
Releasing a new version
All the concepts from the actions/toolkit release docs apply. Please read that first!
Once the changes are merged into main, a repo maintainer should:
- Bump the package version by running
npm version [major|minor|patch]. We adhere to SemVer 2.0 to the best of our ability. Commit the changes to
package-lock.jsonand push them to main.
- Draft a new release pointing to the ref of the version bump you just made. Publish the release to the marketplace when complete.
- Finally: update the corresponding "major tag" (v1, v2, v3, etc) to point to the specific ref of the release you just made. For example, if we just released
v1.1.0, we would rewrite the
v1tag like this:
git tag -fa v1 v1.1.0 -m "Update v1 tag to point to v1.1.0" git push origin v1 --force
This repository uses a tool called Licensed to verify third party dependencies. You may need to locally install licensed and run
licensed cache to update the dependency cache if you install or update a production dependency. If licensed cache is unable to determine the dependency, you may need to modify the cache file yourself to put the correct license. You should still verify the dependency, licensed is a tool to help, but is not a substitute for human review of dependencies.
GitHub Actions Team