Jakub Narebski <jnareb@xxxxxxxxx> writes:
> or the test should use
>
> $maxload = -1;
>
> to artificially force 'load too high' situation.
One related thing that bugs me somewhat is that there is no corresponding
test to make sure that "too loaded" does not trigger when it shouldn't.
But it is harder to arrange (there is no safe $maxload value you can
hardcode in the test and guarantee the system will not loaded that high),
so you need to teach the get_loadavg() to lie under test only for the sake
of running the test, which is backwards---so I'd say that is not worth it.
Here is my attempt to reword the commit log message from Brian (the "-1"
one, squashed into a revert of the one from yesterday, the latter of which
I already pushed out). I just added the first paragraph to better justify
the reason why we are testing the codepath that would never be exercised
in real life on platforms that lack /proc/loadavg.
Subject: t9501: Re-fix max load test
Revert the previous attempt to skip this test on platforms where we
currently cannot determine the system load. We want to make sure that
the max-load-limit codepath produces results cleanly, when gitweb is
updated and becomes capable of reading the load average by some other
method.
The code to check for load returns 0 if it doesn't know how to find
load. It also checks to see if the current load is higher than the
max load. So to force the script to quit early by setting the maxload
variable negative which should work for systems where we can detect
load (which should be a positive number) and systems where we can't
(where detected load is 0)
Signed-off-by: Brian Gernhardt <brian@xxxxxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html