Open DonaldChung-HK opened 1 year ago
I think we should create some sort of cleaning python script. such as based trimming a JSON object base on size, build number, and latest detected fail date so that we can keep the file size in check and retire old data
So the problem with the high influx of fail is that for the by-build history files we are saving all the stack traces instead of just the latest one (to prevent actual loss of data since the updating mechanism is not very robust), we were flooded by 10x120 fails per pipeline which exponentially increases the file size to over 150MB when usually it is just around 2MB per file.
I have implemented 2 bash scripts that will break down the files if they are too big (~90MB) and join them when performing GitHub actions in #5
This is the likely cause fo build fail if the dashboard build successfully but
auto-commit
failed/timeout (saving the new JSON file).If individual files exceed 100MB GitHub will refuse a push. This will occur either if there is a large influx of new test fail or total number of unique test fail build up over time. This will likely to happen if the tests are python based as they tend to output larger stacktrace.
Here are some solutions on how to deal with such situation.
If it is just a one off large influx of test
is_completed
astrue
inhistory/{pipeline_name}/{pipeline_name}_by_build_fail_pickle.json
so that the search algorithm skip over the problematic builds.If the tests build-up over time:
Finally, we can add a process where wesplit the files which exceed 100MB and join them before processing. However, you might run out of memory if the files gets too big as python is inefficient in JSON reading which use ~ 7-8x of memory of JSON size