.. _/stories/deferred:

Deferred
========
*As tmt contributors we want to keep separately some older, postponed but still valuable ideas for possible future use.*


This section contains user stories which are not planned to be implemented in the near future. They still might be useful for inspiration or even might be later resurrected from the sleep.

.. _/stories/deferred/gate:

gate
^^^^

Gates relevant for testing

*As a user I want to easily enable plan for selected gates.*

.. note:: This is a draft, the story is not implemented yet.

Multiple gates can be defined in the process of releasing a change.
Currently we define the following gates:

merge-pull-request
    block merging a pull request into a git branch
add-build-to-update
    attaching a build to an erratum / bodhi update
add-build-to-compose
    block adding a build to a compose
release-update
    block releasing an erratum / bodhi update

Each plan can define one or more gates it should be blocking.
Attached is an example of configuring multiple gates.


**Examples:**


.. code-block:: yaml

   /test:
       /pull-request:
           /pep:
               summary: All code must comply with the PEP8 style guide
               # Do not allow ugly code to be merged into the main branch
               gate:
                   - merge-pull-request
           /lint:
               summary: Run pylint to catch common problems (no gating)
       /build:
           /smoke:
               summary: Basic smoke test (Tier1)
               # Basic smoke test is used by three gates
               gate:
                   - merge-pull-request
                   - add-build-to-update
                   - add-build-to-compose
           /features:
               summary: Verify important features
       /update:
           # This enables the 'release-update' gate for all three plans
           gate:
               - release-update
           /basic:
               summary: Run all Tier1, Tier2 and Tier3 tests
           /security:
               summary: Security tests (extra job to get quick results)
           /integration:
               summary: Integration tests with related components


**Status:** idea

.. _/stories/deferred/interactive:

interactive
^^^^^^^^^^^


*Provide way similar to git rebase --interactive*

.. note:: This is a draft, the story is not implemented yet.

Provide users with list of steps and let them edit them. Allow adding commands between, or at least interactive "pause". When user would be finished with single step, just continue recipe. Do not force users to remember all steps when working with them. Make it possible to repeat single step or abort current run. Allow repeating some steps just by repeating lines with task.

**Examples:**


.. code-block:: yaml

   tmt run --all --interactive



.. code-block:: yaml

   tmt run --continue



.. code-block:: yaml

   tmt run --abort


**Status:** idea

.. _/stories/deferred/restraint:

restraint
^^^^^^^^^


*As a tester I want the option to execute tests using the ``restraint`` harness.*

.. note:: This is a draft, the story is not implemented yet.

Restraint is the default harness in beaker for RHEL8 and
beyond. In order to provide compatibility with beaker
style tests, I would like a way to invoke ``tmt`` using
the Restaint harness. This would enable Restraint tests to
be invoked by ``tmt`` without modification. Some common
commands include ``rstrnt-reboot``, ``rstrnt-abort``, and
``rstrnt-report-result``.

Although implementation of the full execute step plugin has
been deferred, backward compatibility scripts have been
provided for several most commonly used restraint commands:

rstrnt-abort
    :ref:`/stories/features/abort`

rstrnt-reboot
    :ref:`/stories/features/reboot`

rstrnt-report-log
    :ref:`/stories/features/report-log`

rstrnt-report-result
    :ref:`/stories/features/report-result`


**Examples:**


.. code-block:: yaml

   tmt run --all execute --how restraint


**Status:** idea