| commit | 8488ae024860f0b4a4cd81c5e22c6e39de1e5588 | [log] [tgz] |
|---|---|---|
| author | John Grossman <johngro@fuchsia.infra.roller.google.com> | Wed Apr 09 15:42:24 2025 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Apr 09 15:43:44 2025 -0700 |
| tree | a853e05dee666d3d2ac4eee685a43e3ae7137700 | |
| parent | 3cffadf2f5f7eb5e4acbe80f4bc0867eae006134 [diff] |
[roll] Roll fuchsia [pager][test] Add a time limiter to race regression tests. There are a few different pager tests that we have which are attempting to exercise race situations which, in the past, have led to failures. In general, these races were hard to reproduce in the past, so the tests attempt to set up a similar race, repeated 1000, or even 10000 times trying to catch a regression. While not perfect, what this does for us is give us a lot of chances during the automated test runs to catch any potential regression. Even if one pass of 1000 attempts does not find anything, the assumption is that if everyone is trying 1000 times, the regression would eventually show up in CI/CQ as a flake. So, the more iterations we can get in the time that we have on each run, the better off we are. Unfortunately, there is another side to this coin. If the test is running in a naturally slow environment (say, TCG QEMU for RISCV), and the test harness is also very overloaded, it is possible that we might time the test out trying to get to our iteration count, just because things happen to be very slow in this pathologically bad situation. So, add a time limit to the system as well. Basically, try to get X iterations in within an absolute time limit of Y. If we run out of time, don't fail the test, but do print a warning saying that we didn't get all of the trials in that we would have liked to. Most of the time, we expect these things to run to completion, but even if they only get a fraction of their attempts into a test run, it is better that nothing (and also better than causing false positive test flake). For now, the iteration count limits have been kept as they were, and the timeout used has been set to 60 seconds. CI/CQ test timeouts seem to be on the order to 2 minutes right now, so hopefully this will avoid flake, even in worst case scenarios. Original-Fixed: 389991524 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1249107 Original-Revision: 8c5c7f4ada929056c155f8403b6089c4da9cfd84 GitOrigin-RevId: 25dbe4af31bebc310e952465612e72e2538064cf Change-Id: I8eb6ea40966a4ef8546934363b0446915c80dab8
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance in one of the communication channels documented at get involved.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.