Contributing
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.
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
This project is written in TypeScript, a typed variant of JavaScript, and we use Prettier to get a consistent code style.
Because of how GitHub Actions are run, the source code of this project is transpiled from TypeScript into JavaScript. The transpiled code (found in 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:
npm install
- 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
- Update
dist/index.js
usingnpm run build
. This creates a single javascript file that is used as an entrypoint for the action - 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 topackage.json
andpackage-lock.json
and 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 thev1
tag like this:
git tag -fa v1 v1.1.0 -m "Update v1 tag to point to v1.1.0"
git push origin v1 --force
Licensed
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.
Resources
Thanks!
GitHub Actions Team