The following is a set of guidelines for contributing to actions-rs
GitHub Actions.
Use meta
repo issues list to talk about things you want to see in actions-rs
.
Before creating bug reports, please check the GitHub issues list for Action you are using
as you might find out that you don't need to create one.
When you are creating a bug report, please include as many details as possible.
Note: If you find a closed issue that seems like it is the same thing that you're experiencing,
open a new issue and include a link to the original issue in the body of your new one.
Bugs are tracked as a GitHub issues in the corresponding Action repositories.
Explain the problem and include additional details to help maintainers reproduce the problem:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Provide specific examples to demonstrate the steps.
Include links to the workflow files (pointing to the specific commit, and not to the
master
branch) and attach step logs to the issue (consider enabling debug logs first) - Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
- Explain which behavior you expected to see instead and why.
New ideas are welcomed!
Feature requests are also tracked as a GitHub issues in the corresponding Action repositories.
Explain the idea and include as much additional details as possible:
- Use a clear and descriptive title for the issue
- Describe your motivation and how Rust community could benefit from this change
- Provide workflow step examples, if applicable
- Include links to the related tools, alternative implementations or any other information sources
Please note that maintaining backwards compatibility is critically important; any changes that require new major version to be published will be postponed till there will be enough changes to make a new major release.
If your change introduces any new functionality or breaks the backwards compatibility in any matter - do not rush to create a Pull Request at all.
Do not waste your time on that, check Backwards compatibility section first for motivation, and create an issue first, explain why do you want to make this change and let the discussion happen.
Code you are contributing should pass the following checks:
- Should change only one specific thing
- Not raising any compiler errors or warnings
- Conforms to formatting rules (use
npm run format
command) - Not raisiing any lint warnings (use
npm run lint
command) - Should pass the CI tests
Now create a GitHub Pull Request with patch:
- Ensure the Pull Request description clearly describes the problem and solution
- Include the relevant issue number if applicable
- Ensure that all the checks from above are passing