Log
NOTE: The following assumes logging will be done during rendering, but that is no longer the case, thus should be changed to logging on editing the page.
The Observer class implements a test observer that log status changes. This list the overall results for modules that has tests, and the entries will be added conditionally during rendering. The log entry will be added if the overall outcome of the tests has changed from the previous run, or if there are no results from earlier. The logged page will be the tested page, and the user will be a specific one that is created for this purpose.
By having a status change log it will be easier to track down where and when a change happen, and then how to fix the problem. Often the status change will be at the same time that someone is editing the page, but that is not always the case. The rendering can take place some time after a change on a related page, so it is not necessarily the user triggering the rendering that did the change that is the reason for the status change.
The change will typically happen when rendering is triggered, and at that point the page props are already saved, and that can happen because a more or less random user visits the page. It is probably not necessary to log who did the edit that created the ripple that ultimately lead to a status change in most cases, and it can also be difficult to identify the correct edit. Instead of using the user who triggered the rendering, or the user who previously did the edit, a system user is registered and used. The system user will presumably be something like “Test observer”, “Test logger”, or “Test manager” for those cases. A name like “observer” is a bit more generic than “logger”, but the “manager” form is already in use by the Flow-system.
NOTE: Only use the following if a flag “log on render” is set?
One possible solution is to save a notice about a changed render state to memcached instead of page props, and to use that as basis for logging, and other status tracking if it exists and are different from page props. If the state notice in memcached does not exist, then all status tracking will happen according to page props, and then the state notice will be recreated. The state notice will be deleted on page save. This will make new log entries as the memcached state notices disappears or changes.
In some cases the status change can be detected during the save action, and then it is possible to log the test status change with the correct user. This is although not trivial, as the status change for one page can be triggered by some other page, and a cascade of log entries created.
There are other special users like User:Maintenance script and User:Flow talk page manager. The special user that logs the status changes should be handled the same way.
NOTE: Following is not implemented.
At the top of the page there is a link to the special log page.
Usage
The user is identified through its user id, so it can be renamed. It could be that it is better to use a fixed name, as this can be more easily handled on a server farm.
{
"config": {
"ObserverID": 3
}
}
The special user must be manually created, and unless created status change log entries will not be made.
Entries
Log entries will be made on changes, and it is the final state that is logged
- track/good – all tests passed
- track/fail – some tests failed
- track/skip-good – all tests passed, but some tests marked “skip” (i.e. could be a pending failure)
- track/skip-fail – some tests failed, and some tests also marked “skip”
- track/todo-good – all tests passed, but some tests marked “todo” (i.e. could be a pending failure)
- track/todo-fail – some tests failed, and some tests also marked “skip”
- track/missing – missing test page
- track/unknown – unknown test page