Skip to content

Latest commit

 

History

History
126 lines (82 loc) · 4.29 KB

CONTRIBUTING.md

File metadata and controls

126 lines (82 loc) · 4.29 KB
Raw

Contributing to cypress-allure-plugin

Firstly, thanks for considering contributing to cypress-allure-plugin. To make it a really great tool we need your help.

cypress-allure-plugin is Apache 2.0 licenced and accepts contributions via GitHub pull requests. There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code.

Certificate of Origin

By contributing to this project you agree to the Developer Certificate of Origin. This was created by the Linux Foundation and is a simple statement that you, as a contributor, have the legal right to make the contribution.

To signify that you agree to the DCO you must signoff all commits:

git commit --signoff

Getting Started

  • Fork the repository on GitHub
  • Read the README for getting started as a user and learn how/where to ask for help
  • If you want to contribute as a developer, continue reading this document for further instructions
  • Play with the project, submit bugs, submit pull requests!

Contribution workflow

1. Set up your environment

  1. You'll need the following tools:
  1. Fork this repository and clone it by running:
git clone git@github.com:<yourusername>/cypress-allure-plugin.git
  1. Install dependencies:
cd cypress-allure-plugin
npm install
  1. You can run tests to validate that setup is fine:
  • npm run test:prepare:basic - run tests from cypress/e2e/basic with allure results copied into cypress/e2e/fixtures/basic
  • npm run test:prepare:cucumber - run tests from cypress/e2e/cucumber with allure results copied into cypress/e2e/fixtures/cucumber
  • npm test - run tests from cypress/e2e/results against these allure results in cypress/e2e/fixtures

2. Find a feature to work on

  • Look at the existing issues to see if there is anything you would like to work on. If don't see anything then feel free to create your own feature request.

  • If you are a new contributor then take a look at the issues marked with good first issue.

  • Make your code changes within a feature branch:

    git checkout -b <feature-name>

  • Try to commit changes in logical units with a commit message in this format. Remember to signoff your commits.

  • Don't forget to update the docs if relevent. The README is where docs usually live.

  • Make sure the tests pass and that there are no linting problems.

3. Create a pull request

Push your changes to your fork and then create a pull request to origin. Where possible use the PR template.

You can mark a PR as wotk in progress by prefixing the title of your PR with WIP:.

Commit Message Format

We would like to follow the Conventional Commits format for commit messsages. The full specification can be read here. The format is:

<type>: <description>

[optional body]

[optional footer]

Where <type> is one of the following:

  • feat - a new feature
  • fix - a bug fix
  • chore - changes to the build pocess, code generation or anything that doesn't match elsewhere
  • docs - documentation only changes
  • style - changes that don't affect the meaning of the code (i.e. code formatting)
  • refactor - a change that doesn't fix a feature or bug
  • test - changes to tests only.

The body should include details of what changed and why. If there is a breaking change then the body should start with the following: BREAKING CHANGE.

The footer should include any related github issue numbers.

An example:

feat: Added new command to run cypress

A new command has been added to run cypress. The
command will execute cypress for single spec file with option `--no-exit`

Fixes: #123

A tool like Commitizen can be used to help with formatting commit messages.