Some jobs on GA apparently consume a lot of CPU resources, possibly hindering
communication between master and runner. This only seems to happen on Linux+ASAN
and macOS. For these jobs, keep one core idle.
Closes GH-12742
FilesystemTest::testSharedGet() uses too much memory and crashes GA. It was
already ignored by adding the `@skip` attribute, but the code changed and the
replacement stopped working.
Closes GH-12570
The path to mysql.exe changed. Fortunately, chocolately puts the folder
containing the exe in the PATH environment variable, so we don't even
need to provide an absolute path.
See ef6bbaa. We previously ran into crashes that are apprently related to a
decrease in memory on never runners. The crash can be avoided by increasing the
swap file.
Closes GH-12267
Keep this up to date in all non-security-only branches, because the node.js
runtime for older versions might get deprecated in the future and fixing this
for all branches at once is easier.
This allows https://nielsdos.github.io/php-benchmark-visualisation/ to only
show commits from master (or a specific branch). Otherwise we get confusing,
undulating commits from different branches, with potentially wildly different
performance.
Closes GH-12101
We get the following errors:
profiling:./ext/pdo_oci/.libs/oci_statement.gcda:Cannot open
...
It seems these extensions were never tested for coverage. Having coverage here
would be nice, but since they are not actively worked on I don't want to
investigate the issue.
On one of the nightly CI builds last week, there were test failures in
mbstring which appear like they might be related to SIMD-accelerated
code. The function which failed testing has multiple implementations,
and the specific implementation which is used depends on the features of
the host CPU and the build configuration.
The CI build log does not offer any clues about what implementation
was actually used when the tests failed. If the same thing happens
again, it will be helpful to (at least) know what CPU features the host
CPU supports. This will also be helpful when diagnosing any other CI
build failures which relate to CPU-specific code (or those which
related to external packages such as ICU).
It would be better to print even more information about the build
configuration. It would also be better to print host CPU information
on Windows CI builds as well.
