[ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
[ < Uploading a patch for review ] | [ Up : Lifecycle of a merge request ] | [ Patch countdown > ] |
3.3.2 Automated testing
When a merge request is opened, a bot automatically adds the
Patch::new
label to it, and it enters the countdown cycle.
GitLab triggers automated testing, which ensures that the patch
completes make
, make check
, and make doc
.
After testing succeeds, the patch author or a reviewer should
check regression test results. To find these, first view the log
for the make check
job. Currently, this can be reached by
clicking the second of the three green circles with check marks
next to the text “Merge request pipeline #… passed”.
This opens a small window; click the line containing the word
‘check’.
On the job page, you will find a direct link to the regression test visual comparison page at the very end of the log text. Around ten lines before the last line, look for the text “Results can be viewed at ...”
If tests display no obviously bad differences, the patch can be
advanced to Patch::review
. If the size of the regression
test visual differences allows it, please paste screenshots of
them on the merge request page for easier review. Otherwise,
simply paste a link to the that page. Also, for changes that are
by nature not expected to yield regression test differences, such
as documentation improvements, it is not necessary to leave a
comment at all. In case any of the testing steps fails, the patch
should be set to Patch::needs_work
. When revisions are
made, this process repeats (if the regression test diff is not
changed by the latest iteration, a comment stating so can replace
posting screenshots again).
[ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
[ < Uploading a patch for review ] | [ Up : Lifecycle of a merge request ] | [ Patch countdown > ] |