Skip to content

Latest commit

 

History

History
64 lines (48 loc) · 3.27 KB

CONTRIBUTING.md

File metadata and controls

64 lines (48 loc) · 3.27 KB
Raw

How to contribute

Fork the repository and make some changes. Once you're done with your changes send a pull request. You have to agree to the license. Thanks! If you have questions, visit us on irc.freenode.net in #opensuse-factory or ask on our mailing list opensuse-factory@opensuse.org

How to get started

It can be beneficial to learn how an openQA job is executed. To setup your own openQA instance, please refer to the documentation of the openQA project.

Please, find up-to-date documentation references on the official openQA project web-page.

If you are looking for a task to start with, check out the openQA Tests Redmine project. Look for tickets with [easy] or [easy-hack] tags.

Relevant documentation

Reporting an issue

As mentioned above, we use Redmine as issue tracking tool. In case you found some problem with the tests, please do not hesitate report a new issue Please, refer to the template.

If in doubt, contact us, we will be happy to support you.

Coding style

The project follows the rules of the parent project os-autoinst. and additionally the following rules:

  • Take example boot.pm as a template for new files
  • The test code should use simple perl statements, not overly hacky approaches, to encourage contributions by newcomers and test writers which are not programmers or perl experts
  • Update the copyright information with the current year and SUSE LLC as the legal entity. For new files make sure to only state the year during which the code was written.
  • Use my ($self) = @_; for parameter parsing in methods when accessing the $self object. Do not parse any parameter if you do not need any.
  • DRY

Preparing a new Pull Request

  • All code needs to be tidy, for this use make prepare the first time you set up your local environment, use make tidy or tools/tidy locally to ensure your new code adheres to our coding style.
  • Every pull request is tested by the travis CI for different perl versions, if something fails, run make test (don't forget to make prepare if your setup is new) but the travis results are available too, in case they need to be investigated further
  • Whenever possible, provide a verification run of a job that runs the code provided in the pull request

Also see the DoD/DoR as a helpful (but not mandatory) guideline for new contributions.