From Fedora Project Wiki

m (Adamwill moved page User:Tflink/taskotron contribution guide to QA:Taskotron contribution guide: really shouldn't be a user page)
(revise page with correct repo links and better text)
Line 1: Line 1:
This is an initial guide to getting started with contributing to taskotron, please let us know if you find any errors in this document or if something doesn't make sense
== Repositories ==


= Introduction =
The repositories for the various components of [[Taskotron]] can be found on [https://pagure.io Pagure]:


= Getting the Code =
* [https://pagure.io/taskotron/libtaskotron libtaskotron]
For now, all taskotron related code is on bitbucket. You can find most of the needed repositories under the [https://bitbucket.org/fedoraqa fedoraqa team].
* [https://pagure.io/taskotron/taskotron-trigger taskotron-trigger]
* [https://pagure.io/taskotron/execdb ExecDB]
* [https://pagure.io/taskotron/resultsdb ResultsDB]
* [https://pagure.io/taskotron/resultsdb_frontend ResultsDB frontend]
* [https://pagure.io/taskotron/resultsdb_api ResultsDB API client library]
 
The repositories for the tasks developed alongside Taskotron itself are in the [https://bitbucket.org/fedoraqa Fedora QA project on Bitbucket]:


* [https://bitbucket.org/fedoraqa/libtaskotron libtaskotron]
* [https://bitbucket.org/fedoraqa/depcheck-mk-2 depcheck mk 2]
* [https://bitbucket.org/fedoraqa/taskotron-trigger taskotron trigger]
* [https://bitbucket.org/fedoraqa/task-rpmlint task-rpmlint]
* [https://bitbucket.org/fedoraqa/task-rpmlint task-rpmlint]
* [https://bitbucket.org/fedoraqa/task-depcheck task-depcheck]
* [https://bitbucket.org/fedoraqa/task-upgradepath task-upgradepath]
* [https://bitbucket.org/fedoraqa/task-rpmgrill task-rpmgrill]
* [https://bitbucket.org/fedoraqa/task-dockerautotest task-dockerautotest]


Other repos which are potentially of interest are:
If you need team membership, send a message out to qa-devel@ or file a ticket in [[QA/Phabricator]] against the infrastructure project.
* [https://bitbucket.org/rajcze/resultsdb resultsdb]
* [https://bitbucket.org/rajcze/resultsdb_frontend resultsdb_frontend]
* [https://bitbucket.org/rajcze/resultsdb_api resultsdb client]


If you need team membership, send a message out to qa-devel@ or file a ticket in phabricator against the infrastructure project.
== Issue and code change tracking ==


= Getting the Tools =
Tracking of issues and code changes for all Taskotron projects happens in the [https://phab.qa.fedoraproject.org Fedora QA instance] of [[QA/Phabricator|Phabricator]]. Please see [[QA/Phabricator#issues-diffs|this section of the page]] for general instructions on submitting issues and 'diffs' in Phabricator.


A general list of the tools we are using (read: should be installed on dev machines) and available in the Fedora repos are:
== Taskotron-specific instructions ==
* git
* py.test
* gitflow


There are some specific considerations for contributing to Taskotron components.


== gitflow ==
=== gitflow ===


Gitflow is a git branching strategy that has been used successfully in the blocker tracking app and several Fedora infra apps.
Gitflow is a git branching strategy that has been used successfully in the blocker tracking app and several Fedora infra apps.
Line 35: Line 37:
{{admon/note|Use the develop branch|When using gitflow, the current in-development branch is <code>develop</code>, not <code>master</code>. Be careful not to start developing against an older branch}}
{{admon/note|Use the develop branch|When using gitflow, the current in-development branch is <code>develop</code>, not <code>master</code>. Be careful not to start developing against an older branch}}


== Arcanist ==
=== Tests ===
 
Taskotron components usually have test suites built on [http://docs.pytest.org/en/latest/ Pytest]. Ensure you have {{package|pytest}} installed to run the tests.


For instructions on installing and using the 'Arcanist' tool to submit changes for review, see [https://phab.qa.fedoraproject.org/w/contributing/ the Contributing page on the Phab wiki].
=== Linting ===


As we are using code linting, you will also need the flake8 tool - run {{code|sudo dnf install python-flake8}} to install it.
As we are using code linting, you will also need the flake8 tool - run {{code|sudo dnf install python-flake8}} to install it.


= General Thoughts and Conventions =
=== General Thoughts and conventions ===


These will be fleshed out more in the near future but in general:
* Be smart
* Be smart
* All code going into develop branches '''MUST''' be reviewed
* All code going into develop branches '''MUST''' be reviewed
* All code should have good unit tests where appropriate
* All code should have good unit tests where appropriate
** When in doubt, ask
** When in doubt, ask

Revision as of 02:57, 10 February 2017

Repositories

The repositories for the various components of Taskotron can be found on Pagure:

The repositories for the tasks developed alongside Taskotron itself are in the Fedora QA project on Bitbucket:

If you need team membership, send a message out to qa-devel@ or file a ticket in QA/Phabricator against the infrastructure project.

Issue and code change tracking

Tracking of issues and code changes for all Taskotron projects happens in the Fedora QA instance of Phabricator. Please see this section of the page for general instructions on submitting issues and 'diffs' in Phabricator.

Taskotron-specific instructions

There are some specific considerations for contributing to Taskotron components.

gitflow

Gitflow is a git branching strategy that has been used successfully in the blocker tracking app and several Fedora infra apps.

Note.png
Use the develop branch
When using gitflow, the current in-development branch is develop, not master. Be careful not to start developing against an older branch

Tests

Taskotron components usually have test suites built on Pytest. Ensure you have Package-x-generic-16.pngpytest installed to run the tests.

Linting

As we are using code linting, you will also need the flake8 tool - run sudo dnf install python-flake8 to install it.

General Thoughts and conventions

  • Be smart
  • All code going into develop branches MUST be reviewed
  • All code should have good unit tests where appropriate
    • When in doubt, ask