This test queries `extOutput` for the first line of output of the
command which was executed when snmpd started (`HexTest` in snmpd.conf).
Since there is no `/bin/sh` on Windows, no command would be run, and as
such we received an empty string. We fix that by dynamically adjusting
snmpd.conf to run a JScript which has the same output as bigtest.
We also make the test diff more helpful in case of failures, where so
far we only would have known that the output had a different message
digest.
ABI breaks are not supposed to happen after feature freeze, i.e. when
the PHP API numbers have been bumped. To make it easier to notice
inadvertent ABI breaks, we automatically add an "ABI break" label to
all PRs which modify public (aka. installed) header files. Some of
these modifications do not constitute an ABI break (e.g. adding a
comment to a header file), but we rely on natural intelligence to sort
that out. That means these labels should be removed manually, if they
are not appropriate, but if they are, the PR should not be merged into
any stable branch. For the master branch, where ABI breaks are
permissible, the labels should still be removed if irrelevant, but kept
when the PR is merged.
Since tests are futile[1], we leave that to further (test) PRs.
[1] <https://github.com/php/php-src/pull/15682#issuecomment-2323060586>
Closes GH-15682.
These were needed mostly for the PHP <= 8.3 pspell extension. The
nchant2-hunspell gets installed automatically as a dependency with
enchant2-dev if needed.
That was broken when CI was moved to GH, since `APPVEYOR_BUILD_FOLDER`
is no longer set; instead we use `GITHUB_WORKSPACE` which has the same
meaning.
Closes GH-15896.
When the avif support was first added (GH-7026), php-src did not
use GitHub Actions. When we moved to GitHub Actions for CI, the
`--with-avif` option nor the `libavif-dev` dependencies were not
added.
Cirrus CI still runs the tests, and now that we no longer use
Travis CI, this brings parity to test avif on x64 tests on
GitHub Actions as well.
`libavif-dev` package's x86 builds seem to be missing[^1][^2] on older
Ubuntu versions, so this commit only adds it for x64 builds.
[^1]: https://packages.ubuntu.com/jammy/libavif-dev
[^2]: https://packages.ubuntu.com/noble/libavif-dev
Travis was suspended https://github.com/php/php-src/pull/15314
This removes 404 errored Travis image in README, travis configuration
directory and YAML file and usages in tests.
[skip ci]
Co-authored-by: Gina Peter Banyard <girgias@php.net>
Git 2.46.0 accidentally broke git diff --exit-code for files flagged with -diff.
Add the -a flag to restore the previous behavior. This issue is already fixed in
gits next branch.
Only the master branch should use vs17; older branches still should
stick with vs16. And while not strictly necessary, older branches
should better stick with windows-2019 runners.
PHP 8.4 is supposed to be built with vs17 (aka. Visual Studio 2022)[1],
so we also do this for CI.
We mark gh8841.phpt as xfail for known reasons.
[1] <https://windows.php.net/>
This repeats the sync as noted in the GH-13591 and the discussion
https://news-web.php.net/php.internals/124472
The CODEOWNERS file is related to the targeted branch in the pull
request and not only the master branch.
- Added a note to change the earliest supported PHP branch and not only
master branch
- Synced GitHub ID's and paths across the PHP-8.2, PHP-8.3 and master
branches
- Add note how changes here should be analogous to bug fixes
with a link to CONTRIBUTING.md which describes which branch to
target
The Windows CI of the `PHP-8.2` to `PHP-8.3` branches still use the
`php-sdk-2.2.0` which is almost five years old, and does not fetch the
updated dependencies from https://downloads.php.net/~windows.
The `master` branch CI uses `php_downloads_server_migration_v1`, which
has been superseded a few months ago[1]. So switching to the
`php-sdk-2.3.0` makes sense there, too.
[1] <php/php-sdk-binary-tools@19c8ccb>
Closes GH-14991.
This reverts commit 0bcc1e613b.
It turns out that GitHub expects all users listed in CODEOWNERS to have
write access to the repository, and @youkidearitai does not currently
have such access. I was not aware of this earlier, and still hope that
he can be added back later, since he is very helpful when it comes
to reviewing GitHub issues and pull requests.
Saki Takamachi