Use bors-ng to create and upload test images

- Reinstate Travis deploy phase
- Better labeling of Mergify rules
- Automatic `bors try` by Mergify
- Explain bors in comment message
- Skip push for staging branch
- Re-update docs to current situation

docs/contributors/environment.rst

@@ -203,18 +203,54 @@ He can provide access to a testing server, if a trust relation can be establishe
 Test images
 ```````````
 
-All PR's get build by Travis and some primitive auto testing is
-done. The resulting images get uploaded to Docker hub, under the
-tag name ``mailutest/<name>:<target_branch>-<pr_no>``.
+All PR's automatically get build by Travis, controlled by `bors-ng`_.
+Some primitive auto testing is done.
+The resulting images get uploaded to Docker hub, under the
+tag name ``mailutest/<name>:pr-<no>``.
 
 For example, to test PR #500 against master, reviewers can use:
 
 .. code-block:: bash
 
   export DOCKER_ORG="mailutest"
-  export MAILU_VERSION="master-500"
+  export MAILU_VERSION="pr-500"
+  docker-compose pull
   docker-compose up -d
 
+You can now test the PR. Play around. See if (external) mails work. Check for whatever functionality the PR is
+trying to fix. When happy, you can approve the PR. When running into failures, mark the review as
+"request changes" and try to provide as much as possible details on the failure.
+(Logs, error codes form clients etc).
+
+.. _`bors-ng`: https://bors.tech/documentation/
+
+Additional commits
+``````````````````
+
+Sometimes users add new commits after ``bors try`` was  run automatically.
+In such cases, a reviewer will have to re-issue a ``bors try`` manually in order
+to get the latest changes in the test image. The reviewer will have to be sure the
+build finished successful before pulling the new images.
+
+Any previous reviews get dismissed automatically, whenever a new commit is done afterwards.
+
+When bors try fails
+```````````````````
+
+Sometimes Travis fails when another PR triggers a ``bors try`` command,
+before Travis cloned the git repository.
+Inspect the build log in the link provided by *bors-ng* to find out the cause.
+If you see something like the following error on top of the logs,
+feel free to write a comment with ``bors retry``.
+
+.. code-block:: bash
+
+  The command "git checkout -qf <hash>" failed and exited with 128 during .
+
+Please wait a few minutes to do so, not to interfere with other builds.
+Also, don't abuse this command if anything else went wrong,
+the author needs to try to fix it instead!
+
 Reviewing by git
 ----------------
 
@@ -278,18 +314,6 @@ The following must be done on every PR or after every new commit to an existing
 If git opens a editor for a commit message just save and exit as-is. If you have a merge conflict,
 see above and do the complete procedure from ``git fetch`` onward again.
 
-Test
-````
-
-You can now build and run the containers for testing. See the "`Docker containers`_" section for
-instructions. Play around. See if (external) mails work. Check for whatever functionality the PR is
-trying to fix. When happy, you can approve the PR. When running into failures, mark the review as
-"request changes" and try to provide as much as possible details on the failure.
-(Logs, error codes form clients etc).
-
-.. note:: Github marks positive reviews as obsolete when a new commit is added to a PR.
-  This requires a new review from your side.
-
 Web administration
 ------------------
 

docs/contributors/guide.rst

@@ -56,7 +56,7 @@ PR Workflow
 ````````````
 
 All pull requests have to be against the main ``master`` branch.
-The PR gets build by Travis and some primitive auto testing is done.
+The PR gets build by Travis and some primitive auto-testing is done.
 Test images get uploaded to a separate section in Docker hub.
 Reviewers will check the PR and test the resulting images.
 See the :ref:`testing` section for more info.