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
2025-10-29 17:22:20 +00:00 · 2019-01-24 15:23:25 +02:00
parent faca9983a8
commit 33db705194
5 changed files with 82 additions and 36 deletions
--- a/.mergify.yml
+++ b/.mergify.yml
@@ -1,20 +1,33 @@
 pull_request_rules:
-  - name: 2 approved reviews
+
+  - name: Build testing images; trigger bors try
+    conditions:
+      - -title~=(WIP|wip)
+      - -label~=^(status/wip|status/blocked)$
+    actions:
+      comment:
+        message: |
+          Thanks for submitting this pull request.
+          Bors-ng will now build test images. When it succeeds, we will continue to review and test your PR.
+          
+          bors try
+          
+          Note: if this build fails, [read this](http://mailu.io/master/contributors/environment.html#when-bors-try-fails).
+
+  - name: 2 approved reviews; trigger bors r+
    conditions:
      - -title~=(WIP|wip)
      - -label~=^(status/wip|status/blocked)$
-      - status-success=Travis CI - Pull Request
      - "#approved-reviews-by>=2"
    actions:
      comment:
        message: bors r+

-  - name: Trusted author and 1 approved review
+  - name: Trusted author and 1 approved review; trigger bors r+
    conditions:
-      - author~=^(kaiyou|muhlemmer|mildred|HorayNarea|adi90x|hoellen|ofthesun9|Nebukadneza)$
+      - author~=^(kaiyou|muhlemmer|mildred|HorayNarea|adi90x|hoellen|ofthesun9|Nebukadneza|ionutfilip)$
      - -title~=(WIP|wip)
      - -label~=^(status/wip|status/blocked|review/need2)$
-      - status-success=Travis CI - Pull Request
      - "#approved-reviews-by>=1"
    actions:
      comment:
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,7 +1,10 @@
 branches:
-  except:
-    - staging.tmp
-    - testing.tmp
+  only:
+    - staging
+    - testing
+    - '1.5'
+    - '1.6'
+    - master

 sudo: required
 services: docker
@@ -35,4 +38,10 @@ script:
  - python tests/compose/test.py rainloop 1
  - python tests/compose/test.py roundcube 1
  - python tests/compose/test.py webdav 1
-  - bash tests/deploy.sh
+
+deploy:
+  provider: script
+  script: bash tests/deploy.sh
+  on:
+    all_branches: true
+    condition: -n $DOCKER_UN
--- a/docs/contributors/environment.rst
+++ b/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
 ------------------

--- a/docs/contributors/guide.rst
+++ b/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.
--- a/tests/deploy.sh
+++ b/tests/deploy.sh
@@ -1,16 +1,16 @@
 #!/bin/bash

-# Re-tag images for PR testing
-if [ $TRAVIS_PULL_REQUEST != false ]; then
-    export MAILU_VERSION="${TRAVIS_BRANCH}-${TRAVIS_PULL_REQUEST}"
+# Skip deploy for staging branch
+[ "$TRAVIS_BRANCH" = "staging" ] && exit 0
+
+# Retag in case of `bors try`
+if [ "$TRAVIS_BRANCH" = "testing" ]; then
    export DOCKER_ORG="mailutest"
+    # Commit message is like "Try #99".
+    # This sets the version tag to "pr-99"
+    export MAILU_VERSION="pr-${TRAVIS_COMMIT_MESSAGE//[!0-9]/}"
    docker-compose -f tests/build.yml build
 fi

-
-# Note that in case of a PR, the branch is the one we are merging into
-if [ -n $DOCKER_UN ] && [ -n $DOCKER_PW ] && \
-{ [ "$TRAVIS_BRANCH" = "master" ] || [ "$TRAVIS_BRANCH" = "1.6" ]; }; then
-    docker login -u $DOCKER_UN -p $DOCKER_PW
-    docker-compose -f tests/build.yml push
-fi
+docker login -u $DOCKER_UN -p $DOCKER_PW
+docker-compose -f tests/build.yml push