|
|
@ -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
|
|
|
|
------------------
|
|
|
|
------------------
|
|
|
|
|
|
|
|
|
|
|
|