Apertis Branching Bot (b1b1ded8) at 19 Feb 11:31
Apertis Branching Bot (b1b1ded8) at 28 Nov 15:25
Apertis Branching Bot (b1b1ded8) at 21 Nov 11:46
Apertis Branching Bot (b1b1ded8) at 17 Nov 09:43
Ritesh Raj Sarraf (b1b1ded8) at 12 Sep 13:02
Apertis Branching Bot (b1b1ded8) at 30 Jun 12:38
Apertis Branching Bot (b1b1ded8) at 27 Feb 12:59
Walter Lozano (b1b1ded8) at 24 Jan 15:12
To read the log for the currently running test only, the current
date and time is used with the --since
argument of
journalctl.
Sometimes, tests can run too fast one after the other and the last log entries of the previous test is at the same timestamp as the one running.
That makes the current test parse log entries from the previous test, which is unexpected, and the test fails.
Unfortunately, the --since
argument of journalctl doesn't allow for
more precision than the second.
To fix that, use the current journal cursor instead of time. With this approach, no entries from the previous test is read by the current test
infrastructure/apertis-issues#62
Signed-off-by: Detlev Casanova detlev.casanova@collabora.com
Walter Lozano (b1b1ded8) at 24 Jan 15:09
Using --after-cursor in combination with -t audit does produces the expected output since the filtering logic is applied before and after that the cursor is moved to next valid entry. In this case, using --after-cursor will cause the output to miss the first entry in the log.
To fix it save the cursor also taking into account the type of entry we are interested on, so later when we use it we can safetly check entries with --after-crusor.
infrastructure/apertis-issues#62
Signed-off-by: Walter Lozano walter.lozano@collabora.com
To read the log for the currently running test only, the current
date and time is used with the --since
argument of
journalctl.
Sometimes, tests can run too fast one after the other and the last log entries of the previous test is at the same timestamp as the one running.
That makes the current test parse log entries from the previous test, which is unexpected, and the test fails.
Unfortunately, the --since
argument of journalctl doesn't allow for
more precision than the second.
To fix that, use the current journal cursor instead of time. With this approach, no entries from the previous test is read by the current test
infrastructure/apertis-issues#62
Signed-off-by: Detlev Casanova detlev.casanova@collabora.com
Walter Lozano (b1b1ded8) at 23 Jan 15:46
Using --after-cursor in combination with -t audit does produces the expected output since the filtering logic is applied before and after that the cursor is moved to next valid entry. In this case, using --after-cursor will cause the output to miss the first entry in the log.
To fix it save the cursor also taking into account the type of entry we are interested on, so later when we use it we can safetly check entries with --after-crusor.
infrastructure/apertis-issues#62
Signed-off-by: Walter Lozano walter.lozano@collabora.com
Walter Lozano (b1b1ded8) at 23 Jan 15:31
Walter Lozano (b1b1ded8) at 17 Jan 16:49
Walter Lozano (b1b1ded8) at 17 Jan 16:49
Better fixing of cursor use
In commit 2e59623a a fix to the cursor use was introduced. However, the fix tries to overcome the issue in a wrong way.
The problem is caused by the fact that the cursor is saved before running the test and then it is used to check newer entries of a specific type (audit). Since when journalctl is used with -t the cursor is first moved to the first entry of the specific type the --after-cursor was changed for --cursor to make the test pass.
However, a better approach would be to save the cursor also taking into account the type of entry we are interested on, so later when we use it we can safetly check entries with --after-crusor.
infrastructure/apertis-issues#62
Signed-off-by: Walter Lozano walter.lozano@collabora.com