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
master
Tim Möhlmann 6 years ago committed by GitHub
parent faca9983a8
commit 33db705194
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -1,20 +1,33 @@
pull_request_rules: 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: conditions:
- -title~=(WIP|wip) - -title~=(WIP|wip)
- -label~=^(status/wip|status/blocked)$ - -label~=^(status/wip|status/blocked)$
- status-success=Travis CI - Pull Request
- "#approved-reviews-by>=2" - "#approved-reviews-by>=2"
actions: actions:
comment: comment:
message: bors r+ message: bors r+
- name: Trusted author and 1 approved review - name: Trusted author and 1 approved review; trigger bors r+
conditions: conditions:
- author~=^(kaiyou|muhlemmer|mildred|HorayNarea|adi90x|hoellen|ofthesun9|Nebukadneza)$ - author~=^(kaiyou|muhlemmer|mildred|HorayNarea|adi90x|hoellen|ofthesun9|Nebukadneza|ionutfilip)$
- -title~=(WIP|wip) - -title~=(WIP|wip)
- -label~=^(status/wip|status/blocked|review/need2)$ - -label~=^(status/wip|status/blocked|review/need2)$
- status-success=Travis CI - Pull Request
- "#approved-reviews-by>=1" - "#approved-reviews-by>=1"
actions: actions:
comment: comment:

@ -1,7 +1,10 @@
branches: branches:
except: only:
- staging.tmp - staging
- testing.tmp - testing
- '1.5'
- '1.6'
- master
sudo: required sudo: required
services: docker services: docker
@ -35,4 +38,10 @@ script:
- python tests/compose/test.py rainloop 1 - python tests/compose/test.py rainloop 1
- python tests/compose/test.py roundcube 1 - python tests/compose/test.py roundcube 1
- python tests/compose/test.py webdav 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

@ -203,18 +203,54 @@ He can provide access to a testing server, if a trust relation can be establishe
Test images Test images
``````````` ```````````
All PR's get build by Travis and some primitive auto testing is All PR's automatically get build by Travis, controlled by `bors-ng`_.
done. The resulting images get uploaded to Docker hub, under the Some primitive auto testing is done.
tag name ``mailutest/<name>:<target_branch>-<pr_no>``. 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: For example, to test PR #500 against master, reviewers can use:
.. code-block:: bash .. code-block:: bash
export DOCKER_ORG="mailutest" export DOCKER_ORG="mailutest"
export MAILU_VERSION="master-500" export MAILU_VERSION="pr-500"
docker-compose pull
docker-compose up -d 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 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, 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. 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 Web administration
------------------ ------------------

@ -56,7 +56,7 @@ PR Workflow
```````````` ````````````
All pull requests have to be against the main ``master`` branch. 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. Test images get uploaded to a separate section in Docker hub.
Reviewers will check the PR and test the resulting images. Reviewers will check the PR and test the resulting images.
See the :ref:`testing` section for more info. See the :ref:`testing` section for more info.

@ -1,16 +1,16 @@
#!/bin/bash #!/bin/bash
# Re-tag images for PR testing # Skip deploy for staging branch
if [ $TRAVIS_PULL_REQUEST != false ]; then [ "$TRAVIS_BRANCH" = "staging" ] && exit 0
export MAILU_VERSION="${TRAVIS_BRANCH}-${TRAVIS_PULL_REQUEST}"
# Retag in case of `bors try`
if [ "$TRAVIS_BRANCH" = "testing" ]; then
export DOCKER_ORG="mailutest" 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 docker-compose -f tests/build.yml build
fi 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 login -u $DOCKER_UN -p $DOCKER_PW
docker-compose -f tests/build.yml push docker-compose -f tests/build.yml push
fi

Loading…
Cancel
Save