Creating PRs against forks requries having up-to-date target branches. Pushing
to these currently triggers CI, which is useless as this commit was already
tested upstream. Contributions are tested via pull request.
* Add macos-14 to the push workflow
* Remove hardcoded brew path in configure-macos action
* Include architecture in macos job name
* Add os to ccache-action in macos job
* Add libsodium in brew action
Since we build with the configuration option --with-sodium, adding libsodium to make sure it is installed
* Add fail-fast to macos matrix
* Add macos-14 to the nightly workflow
* Fix adding bison to PATH in workflows
* Fix architecture
* Use version to compare in nightly_matrix.php
* Make sure test-macos artifacts have unique name
* Update .github/nightly_matrix.php
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
---------
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
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
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.
Within the entire repository these are documentation files and CI don't
need to run when they are changed.
This now includes also README.REDIST.BINS, README.md, and similar README
files within the sapi and ext directories.
README files in tests directories are also only for internals
documentations purposes.
