#389 remove Phabricator references
Merged 5 years ago by kparal. Opened 5 years ago by kparal.

file removed
-7
@@ -1,7 +0,0 @@ 

- {

-     "project_id" : "libtaskotron",

-     "conduit_uri" : "https://phab.qa.fedoraproject.org",

-     "arc.land.onto.default" : "develop",

-     "arc.feature.start.default" : "develop",

-     "unit.engine" : "PytestTestEngine"

- }

file removed
-12
@@ -1,12 +0,0 @@ 

- {

-   "linters": {

-     "flake8": {

-       "type": "flake8",

-       "include": "(\\.py$)",

-       "severity.rules": {

-         "(^E)": "warning",

-         "(^F)": "error"

-       }

-     }

-   }

- }

file modified
+2 -2
@@ -111,7 +111,7 @@ 

  Running a Task

  ==============

  

- A relatively simple example task is `rpmlint <https://bitbucket.org/fedoraqa/task-rpmlint>`_.

+ A relatively simple example task is `rpmlint <https://pagure.io/taskotron/task-rpmlint>`_.

  

  The task requires the rpmlint tool to be installed, so be sure to run::

  
@@ -119,7 +119,7 @@ 

  

  To run that task against a koji build with NVR ``<nvr>``, do the following::

  

-   git clone https://bitbucket.org/fedoraqa/task-rpmlint.git

+   git clone https://pagure.io/taskotron/task-rpmlint.git

    runtask -i <nvr> -t koji_build task-rpmlint/runtask.yml

  

  This will download the ``<nvr>`` from koji into a temp directory under

file removed
-24
@@ -1,24 +0,0 @@ 

- The linter's behaviour is configured in the .arclint file.

- 

- As the .arclint file parser does not support YAML comments, some documentation

- can be put here if needed. Generic arcanist linter documentation is here:

- https://secure.phabricator.com/book/phabricator/article/arcanist_lint/

- 

- Flake8

- ======

- All PEP8 error codes (E* codes) are considered warnings in Phabricator, so that

- only changes to the modified lines are displayed by default (unlike errors,

- which are always displayed regardless of which lines were modified).

- 

- All PyFlakes error codes (F* codes) are considered errors, because they are

- often introduced when modifying other lines than the one in question, and we

- want to be notified of those.

- 

- Additional Flake8 configuration is stored in tox.ini - it contains configuration

- which is not possible to do in .arclint file.

- 

- If you want to ignore a specific source code line, use '# noqa' comment. If you

- want to ignore the whole file, add '# flake8: noqa' comment. Read more

- documentation about flake8 at:

- https://flake8.readthedocs.org/

- 

file modified
+3 -3
@@ -5,10 +5,10 @@ 

  # A list of git repos that are allowed to post a result into a particular namespace

  namespaces_whitelist:

      dist:

-         - https://bitbucket.org/fedoraqa/task-rpmlint.git

-         - https://bitbucket.org/fedoraqa/task-upgradepath.git

+         - https://pagure.io/taskotron/task-rpmlint.git

+         - https://pagure.io/taskotron/task-upgradepath.git

          - https://pagure.io/task-abicheck.git

-         - https://bitbucket.org/fedoraqa/task-rpmgrill.git

+         - https://pagure.io/taskotron/task-rpmgrill.git

          - https://github.com/fedora-python/taskotron-python-versions.git

          - https://github.com/fedora-modularity/check_modulemd.git

          - https://pagure.io/taskotron/task-rpmdeplint.git

file modified
+29 -135
@@ -11,23 +11,18 @@ 

  

  Libtaskotron is written mostly in `Python <https://www.python.org/>`_.

  

- Source code

- -----------

- 

- The source code for libtaskotron is available at:

- https://pagure.io/taskotron/libtaskotron

- 

- If you submit patches, please use the process of :ref:`submitting-code`.

  

  .. _taskotron-bugs:

  

- Bugs, issues and tasks

- ----------------------

+ Source code, bugs, tasks

+ ------------------------

+ 

+ The source code for libtaskotron is available at:

+ https://pagure.io/taskotron/libtaskotron

  

- We use `Phabricator <http://phabricator.org/>`_ to track issues and facilitate

- code reviews for several projects related to libtaskotron and Fedora QA.

+ This project is also used to track bugs and tasks.

  

- Our phabricator instance can be found at https://phab.qa.fedoraproject.org/

+ If you submit patches, please use the process of :ref:`submitting-code`.

  

  

  .. _running-tests:
@@ -36,7 +31,7 @@ 

  ---------------------------------

  

  We place a high value on having decent test coverage for the libtaskotron code.

- In general, tests are written using `pytest <http://pytest.org/>` and are broken

+ In general, tests are written using `pytest <http://pytest.org/>`_ and are broken

  up into two types:

  

    * **Unit Tests** test the core logic of code. They do not touch the filesystem
@@ -47,13 +42,9 @@ 

      tests are often much slower than unit tests but they offer coverage which is

      not present in the unit tests.

  

- To run the unit tests::

- 

-   py.test testing/

+ To run the unit tests, execute::

  

- To run the functional and unit tests::

- 

-   py.test -F testing/

+   py.test

  

  

  Continuous integration
@@ -82,52 +73,6 @@ 

  files automatically cleaned up, so that they don't occupy disk space in vain.

  There is a tmpfiles.d template prepared for you, look into ``conf/tmpfiles.d``.

  

- Support tools

- -------------

- 

- There are several tools that, while not required, make the process of developing

- for libtaskotron significantly easier.

- 

- 

- .. _installing-arcanist:

- 

- Arcanist

- ^^^^^^^^

- 

- `Arcanist <https://secure.phabricator.com/book/phabricator/article/arcanist/>`_

- is a command line interface to Phabricator which can be used to submit code

- reviews, download/apply code under review among other useful functions.

- 

- As Arcanist is an interface to Phabricator, we **strongly recommend** that you

- install it using our packages instead of from the upstream git repos (as

- described in upstream documentation). That way, there is no question that the

- Arcanist version used locally is compatible with our Phabricator instance.

- 

- To add our dnf repository containing Phabricator related packages, run::

- 

-   sudo curl https://repos.fedorapeople.org/repos/tflink/phabricator/fedora-phabricator.repo \

-   -o /etc/yum.repos.d/fedora-phabricator.repo

- 

- Once the repository has been configured, install Arcanist using::

- 

-   sudo dnf -y install arcanist

- 

- Arcanist is written in PHP and installing it will pull in several PHP packages

- as dependencies.

- 

- 

- .. _installing-gitflow:

- 

- gitflow

- ^^^^^^^

- 

- The `gitflow plugin for git <https://github.com/nvie/gitflow>`_ is another

- useful, but not required tool that is available in the Fedora repositories.

- 

- To install the gitflow plugin, run::

- 

-   sudo dnf -y install gitflow

- 

  

  .. _submitting-code:

  
@@ -138,9 +83,8 @@ 

  branching model and with the exception of hotfixes, all changes made should be

  against the ``develop`` branch.

  

- While not required, using the `gitflow plugin for git <https://github.com/nvie/gitflow>`_

- is recommended as it makes the process significantly easier. See

- :ref:`installing-gitflow` for instructions on installing gitflow on Fedora.

+ If you want to use the `gitflow plugin for git <https://github.com/nvie/gitflow>`_

+ to make this process more user-friendly, simply install the ``gitflow`` package.

  

  

  Start a new feature
@@ -148,9 +92,13 @@ 

  

  To start work on a new feature, use::

  

-   git flow feature start TXXX-short-description

+   git checkout -b feature/XXX-short-description develop

  

- Where ``TXXX`` is the issue number in Phabricator and ``short-description`` is a

+ or if you want to use gitflow, use::

+ 

+   git flow feature start XXX-short-description

+ 

+ where ``XXX`` is the issue number in Pagure and ``short-description`` is a

  short, human understandable description of the change contained in this branch.

  

  In general, short reviews are better than long reviews. If you can, please break
@@ -160,36 +108,10 @@ 

  Submitting code for review

  ^^^^^^^^^^^^^^^^^^^^^^^^^^

  

- .. note::

- 

-   Make sure to run all unit and functional tests before submitting code for

-   review. Any code that causes test failure will receive requests to fix the

-   offending code or will be rejected. See :ref:`running-tests` for information

-   on running unit and functional tests.

- 

- Code reviews are done through Phabricator, not pull requests. While it is possible

- to submit code for review through the web interface, :ref:`installing-arcanist`

- is recommended.

- 

- You do not need to push code anywhere public before submitting a review. Unless

- there is a good reason to do so (and there are very few), pushing a feature

- branch to origin is frowned on as it makes repository maintenance more difficult

- for no real benefit.

- 

- To submit code for review, make sure that your code has been updated with respect

- to ``origin/develop`` and run the following from your checked-out feature branch::

- 

-   arc diff develop

- 

- The first time that you use Arcanist, it will ask for an API key which can be

- retrieved from a link contained in that prompt.

- 

- Arcanist will create a new code review on our Phabricator instance and prompt

- you for information about the testing which has been done, a description of the

- code under review and people to whom the review should be assigned. If you're

- not clear on who should review your code, leave the ``reviewers`` section blank

- and someone will either review your code or assign the review task to someone

- who will.

+ Make sure to run all unit and functional tests before submitting code for

+ review. Any code that causes test failure will receive requests to fix the

+ offending code or will be rejected. See :ref:`running-tests` for information

+ on running unit and functional tests.

  

  

  Updating code reviews
@@ -199,13 +121,6 @@ 

  the requested changes have been made in your feature branch, commit them and

  make sure that your branch is still up to date with respect to ``origin/develop``.

  

- To update the existing review, use::

- 

-   arc diff develop --update DXXX

- 

- Where ``DXXX`` is the Differential ID assigned to your review when it was

- originally created.

- 

  

  Pushing code

  ^^^^^^^^^^^^
@@ -226,46 +141,27 @@ 

  before starting the merge process, else messy commits and merges may ensue.

  Once ``develop`` is up-to-date, the basic workflow to use is::

  

-     git checkout feature/TXXX-some-feature

+     git checkout feature/XXX-some-feature

      git rebase develop

  

  To merge the code into develop, use one of two commands. If the feature can be

  reasonably expressed in one commit (most features), use::

  

-     git flow feature finish --squash TXXX-some-feature

+     git flow feature finish --squash XXX-some-feature

  

  Else, if the Feature is larger and should cover multiple commits (less common),

  use::

  

-     git flow feature finish TXXX-some-feature

+     git flow feature finish XXX-some-feature

  

- After merging the code, please inspect log messages in case they need to be

- shortened (Phabricator likes to make long commit messages). Groups of commits

- should at least have a short description of their content and a link to the

- revision in differential. Once the feature is ready, push to origin::

+ After merging the code, please inspect git commit description and make it

+ prettier if needed. Groups of commits should at least have a short description

+ of their content and a link to the issue in Pagure. Once the feature is ready,

+ push to origin::

  

      git push origin develop

  

  

- 

- Reviewing code

- --------------

- 

- To review code, use `Phabricator's web interface <https://phab.qa.fedoraproject.org/>`_

- to submit comments, request changes or accept reviews.

- 

- If you want to look at the code under review locally to run tests or test

- suggestions prior to posting them, use Arcanist to apply the review code.

- 

- Make sure that your local repo is at the same base revision as the code under

- review (usually origin/develop) and run the following command::

- 

-   arc patch DXXX

- 

- Where ``DXXX`` is the review id that you're interested in. Arcanist will grab the

- code under review and apply it to a local branch named ``arcpatch-DXXX``. You can

- then look at the code locally or make modifications.

- 

  Writing directives

  ==================

  
@@ -308,11 +204,9 @@ 

  Sphinx has several built-in info fields which should be used to document

  function/method arguments and return data.

  

- 

  The following is an excerpt from `the Sphinx documentation

  <http://sphinx-doc.org/domains.html#info-field-lists>`_

  

- 

  Inside Python object description directives, reST field lists with these fields

  are recognized and formatted nicely:

  

file modified
+2 -2
@@ -12,8 +12,8 @@ 

  a little light on the practical creation of tasks. :doc:`writingtasks`

  and some existing tasks are also good references:

  

- * `rpmlint <https://bitbucket.org/fedoraqa/task-rpmlint>`_

- * `examplebodhi <https://bitbucket.org/fedoraqa/task-examplebodhi>`_

+ * `rpmlint <https://pagure.io/taskotron/task-rpmlint>`_

+ * `task examples <https://pagure.io/taskotron/task-examples>`_

  

  Task description

  ================

file modified
+3 -4
@@ -103,7 +103,7 @@ 

  ^^^^^^^^^^^^

  

  A very simple task from which you can learn all the basics. See its

- `source code <https://bitbucket.org/fedoraqa/task-rpmlint>`_.

+ `source code <https://pagure.io/taskotron/task-rpmlint>`_.

  

  Run the task like this (replace the example NVR with the build you want to

  test):
@@ -120,11 +120,10 @@ 

  * `task-abicheck <https://pagure.io/task-abicheck/>`_

  * `task-python-versions

    <https://github.com/fedora-python/task-python-versions>`_

- * `task-rpmgrill <https://bitbucket.org/fedoraqa/task-rpmgrill>`_

+ * `task-rpmgrill <https://pagure.io/taskotron/task-rpmgrilll>`_

  

  You can also check our

- `example tasks <https://bitbucket.org/account/user/fedoraqa/projects/TEX>`_

+ `task examples <https://pagure.io/taskotron/task-examples>`_

  (warning, some of them might be out of date) or all the rest of the tasks on

- `bitbucket <https://bitbucket.org/fedoraqa/>`_ and

  `pagure <https://pagure.io/group/taskotron>`_ (projects starting with

  *task-*).

file modified
+1 -1
@@ -46,7 +46,7 @@ 

  

  Refer to the :ref:`quick start <quick-run>` guide for the basics.

  

- Using `task-rpmlint <https://bitbucket.org/fedoraqa/task-rpmlint>`_ as an

+ Using `task-rpmlint <https://pagure.io/taskotron/task-rpmlint>`_ as an

  example, the task repository contains the following important files::

  

    task-rpmlint/

file modified
+5 -5
@@ -15,12 +15,12 @@ 

  Examples

  ========

  

- examplebodhi

- ------------

+ bodhi example

+ -------------

  

- `examplebodhi task git repository <https://bitbucket.org/fedoraqa/task-examplebodhi>`_

+ `bodhi example files <https://pagure.io/taskotron/task-examples/blob/master/f/bodhi>`_

  

- The examplebodhi task is a trivial example which takes an update and determines

+ The bodhi example task is a trivial example which takes an update and determines

  a PASS/FAIL results in a pseudo-random fashion. This task wasn't designed to be

  used in production but is useful as a starting point and for development

  purposes.
@@ -28,7 +28,7 @@ 

  rpmlint

  -------

  

- `rpmlint task git repository <https://bitbucket.org/fedoraqa/task-rpmlint>`_

+ `rpmlint task git repository <https://pagure.io/taskotron/task-rpmlint>`_

  

  rpmlint is the simplest of the production tasks. It takes a koji build and runs

  rpmlint on it, reporting results as result-YAML.

file modified
+4 -1
@@ -1,7 +1,10 @@ 

  # This is a common file where different test suites/linters can be configured.

- # Phabricator uses this file when running `arc unit` or `arc lint`.

  

  [flake8]

+ # If you want to ignore a specific source code line, use '# noqa' comment. If

+ # you want to ignore the whole file, add '# flake8: noqa' comment. Read more

+ # documentation about flake8 at:

+ # https://flake8.readthedocs.org/

  max-line-length=99

  

  [pep8]