Skip to content
This repository has been archived by the owner on Oct 13, 2023. It is now read-only.

Latest commit

 

History

History
71 lines (48 loc) · 3.19 KB

CONTRIBUTING.md

File metadata and controls

71 lines (48 loc) · 3.19 KB

Contributing to actions-rs

The following is a set of guidelines for contributing to actions-rs GitHub Actions.

Requesting new Actions

Use meta repo issues list to talk about things you want to see in actions-rs.

Reporting bugs

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.

How do I submit a bug report?

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:

  1. Use a clear and descriptive title for the issue to identify the problem.
  2. Describe the exact steps which reproduce the problem in as many details as possible.
  3. 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)
  4. Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
  5. Explain which behavior you expected to see instead and why.

Feature requests

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:

  1. Use a clear and descriptive title for the issue
  2. Describe your motivation and how Rust community could benefit from this change
  3. Provide workflow step examples, if applicable
  4. Include links to the related tools, alternative implementations or any other information sources

Backwards compatibility

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.

Pull Requests

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:

  1. Should change only one specific thing
  2. Not raising any compiler errors or warnings
  3. Conforms to formatting rules (use npm run format command)
  4. Not raisiing any lint warnings (use npm run lint command)
  5. Should pass the CI tests

Now create a GitHub Pull Request with patch:

  1. Ensure the Pull Request description clearly describes the problem and solution
  2. Include the relevant issue number if applicable
  3. Ensure that all the checks from above are passing