From 6ffe38001574ee17374f3dfab34e133cd991115f Mon Sep 17 00:00:00 2001 From: Kamil Páral Date: Aug 07 2017 13:33:04 +0000 Subject: remove Phabricator references QA Phabricator is now discontinued. --- diff --git a/.arcconfig b/.arcconfig deleted file mode 100644 index e44f980..0000000 --- a/.arcconfig +++ /dev/null @@ -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" -} diff --git a/.arclint b/.arclint deleted file mode 100644 index 290b9d2..0000000 --- a/.arclint +++ /dev/null @@ -1,12 +0,0 @@ -{ - "linters": { - "flake8": { - "type": "flake8", - "include": "(\\.py$)", - "severity.rules": { - "(^E)": "warning", - "(^F)": "error" - } - } - } -} diff --git a/README.rst b/README.rst index e974607..001a9da 100644 --- a/README.rst +++ b/README.rst @@ -111,7 +111,7 @@ There is a tmpfiles.d template prepared for you, look into ``conf/tmpfiles.d``. Running a Task ============== -A relatively simple example task is `rpmlint `_. +A relatively simple example task is `rpmlint `_. The task requires the rpmlint tool to be installed, so be sure to run:: @@ -119,7 +119,7 @@ The task requires the rpmlint tool to be installed, so be sure to run:: To run that task against a koji build with NVR ````, do the following:: - git clone https://bitbucket.org/fedoraqa/task-rpmlint.git + git clone https://pagure.io/taskotron/task-rpmlint.git runtask -i -t koji_build task-rpmlint/runtask.yml This will download the ```` from koji into a temp directory under diff --git a/arclint.readme b/arclint.readme deleted file mode 100644 index 094473c..0000000 --- a/arclint.readme +++ /dev/null @@ -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/ - diff --git a/conf/namespaces.yaml.example b/conf/namespaces.yaml.example index 73902fb..e82f212 100644 --- a/conf/namespaces.yaml.example +++ b/conf/namespaces.yaml.example @@ -5,10 +5,10 @@ namespaces_safe: # 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 diff --git a/docs/source/devguide.rst b/docs/source/devguide.rst index 2a31d9b..e214e11 100644 --- a/docs/source/devguide.rst +++ b/docs/source/devguide.rst @@ -11,23 +11,18 @@ General information Libtaskotron is written mostly in `Python `_. -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 `_ 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 @@ Running unit and functional tests --------------------------------- We place a high value on having decent test coverage for the libtaskotron code. -In general, tests are written using `pytest ` and are broken +In general, tests are written using `pytest `_ 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 @@ up into two types: 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 @@ In the development environment, it's also useful to have taskotron-generated 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 `_ -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 `_ 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 @@ Libtaskotron follows the `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 `_ +to make this process more user-friendly, simply install the ``gitflow`` package. Start a new feature @@ -148,9 +92,13 @@ Start a new feature 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 @@ up features into chunks that are smaller and easier to manage. 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 @@ There will often be requests for changes to the code submitted for review. Once 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 @@ Make sure that your local ``develop`` branch is up-to-date with ``origin/develop 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 `_ -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 @@ extension can easily render into HTML. 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 `_ - Inside Python object description directives, reST field lists with these fields are recognized and formatted nicely: diff --git a/docs/source/formula.rst b/docs/source/formula.rst index 1f0925d..7a270a9 100644 --- a/docs/source/formula.rst +++ b/docs/source/formula.rst @@ -12,8 +12,8 @@ The documentation here is a description of how things are implemented but are a little light on the practical creation of tasks. :doc:`writingtasks` and some existing tasks are also good references: -* `rpmlint `_ -* `examplebodhi `_ +* `rpmlint `_ +* `task examples `_ Task description ================ diff --git a/docs/source/quickstart.rst b/docs/source/quickstart.rst index 908f98f..c9eb2f4 100644 --- a/docs/source/quickstart.rst +++ b/docs/source/quickstart.rst @@ -103,7 +103,7 @@ task-rpmlint ^^^^^^^^^^^^ A very simple task from which you can learn all the basics. See its -`source code `_. +`source code `_. Run the task like this (replace the example NVR with the build you want to test): @@ -120,11 +120,10 @@ Some more real-world tasks include: * `task-abicheck `_ * `task-python-versions `_ -* `task-rpmgrill `_ +* `task-rpmgrill `_ You can also check our -`example tasks `_ +`task examples `_ (warning, some of them might be out of date) or all the rest of the tasks on -`bitbucket `_ and `pagure `_ (projects starting with *task-*). diff --git a/docs/source/runningtasks.rst b/docs/source/runningtasks.rst index 92f7ba6..715cf68 100644 --- a/docs/source/runningtasks.rst +++ b/docs/source/runningtasks.rst @@ -46,7 +46,7 @@ Running tasks Refer to the :ref:`quick start ` guide for the basics. -Using `task-rpmlint `_ as an +Using `task-rpmlint `_ as an example, the task repository contains the following important files:: task-rpmlint/ diff --git a/docs/source/writingtasks.rst b/docs/source/writingtasks.rst index 434b723..2cd70ca 100644 --- a/docs/source/writingtasks.rst +++ b/docs/source/writingtasks.rst @@ -15,12 +15,12 @@ aren't running from git. Also, see :doc:`quickstart` if you haven't already. Examples ======== -examplebodhi ------------- +bodhi example +------------- -`examplebodhi task git repository `_ +`bodhi example files `_ -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 @@ purposes. rpmlint ------- -`rpmlint task git repository `_ +`rpmlint task git repository `_ rpmlint is the simplest of the production tasks. It takes a koji build and runs rpmlint on it, reporting results as result-YAML. diff --git a/tox.ini b/tox.ini index 6f5aa9e..05f2c97 100644 --- a/tox.ini +++ b/tox.ini @@ -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]