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