This reverts commit eed32b752b.
Windows's Winsock getaddrinfo does not consult the hosts file for
"localhost" because an internal hard-coded rule short-circuits first,
so the Add-Content step had no effect on the failing tests. Remove
the ineffective workaround now that a skip guard replaces it.
Co-authored-by: Claude <noreply@anthropic.com>
This reverts commit 7ae25febbb.
CI runs with this change showed Dnscache was already Running on all
Windows jobs and Resolve-DnsName resolved "localhost" successfully,
yet Winsock getaddrinfo still failed. The service start and probe
had no effect on the failing tests, so they add noise without value.
Co-authored-by: Claude <noreply@anthropic.com>
Addrinfo.getaddrinfo on the Windows CI runners fails for "localhost"
regardless of address family (diagnostic commit a69d12aa54 showed
127.0.0.1 literal resolves fine while "localhost" never does under
AF_INET, AF_INET6, AF_UNSPEC, or nil). That rules out the earlier
KB4057932/AF_INET hypothesis and points at the Dnscache service
being stopped on the runner image.
Start Dnscache if not already running (and set it to Automatic),
then Resolve-DnsName localhost to print the OS-level resolver view
to the log. Existing hosts file and diagnostic assert stay in place
so the single CI round exposes both the service state and its
effect on getaddrinfo.
Co-authored-by: Claude <noreply@anthropic.com>
GitHub Actions Windows Server 2022/2025 runner images ship with the
localhost entries commented out in C:\Windows\System32\drivers\etc\hosts
and rely on the DNS Client service's built-in rule. That path is subject
to Microsoft KB4057932 (getaddrinfo fails with WSAHOST_NOT_FOUND after
an AF_INET6 negative cache), which makes Addrinfo.getaddrinfo("localhost",
53, AF_INET, ...) in mrbgems/mruby-socket/test/addrinfo.rb flaky on CI.
Prepend explicit 127.0.0.1/::1 localhost entries to the hosts file on
all three Windows CI jobs (two mingw-gcc matrix entries and Windows-VC)
before running the build, so the resolver avoids the DNS negative cache
path and returns the expected IPv4 address.
Co-authored-by: Claude <noreply@anthropic.com>
Under normal circumstances, `rake -m test` will parallelize not only the build task, but also the test task.
With this patch, `rake -m test:run:serial` will parallelize the build tasks, but the test tasks will be done one by one in sequence.
The name of the task to be added is as follows:
| tasks to be added | corresponding exist tasks
| --------------------- | ----------------
| `test:run:serial` | `test:run`
| `test:run:serial:bin` | `test:run:bin`
| `test:run:serial:lib` | `test:run:lib`
Until now, `windows-latest` meant `windows-2019`, but now it seems that it is being replaced by `windows-2022` in stages.
At the same time, Visual Studio 2019 will be replaced by Visual Studio 2022.
Since mruby's CI is configured to assume Visual Studio 2019, we'll update this and explicitly specify `windows-2022`.
The main reason for failure is to exceed the time limit, and even when it succeeds, there is less than a minute left.
The 10-minute time limit seems to be too short.
With this change, the test code will not be built unless `rake test` is
run, so there will be almost no side effects even if `enable_test` is
always set (but, gems specified by `add_test_dependency` are included
in `libmruby.a`).
Also added are `test: build` task, which only builds the test code
(including the main code), and `test: run` task, which only runs tests
independent of build. Therefore, the idiom for building in parallel and
not running tests in parallel is `rake -m test:build && rake test:run`.
* Skip if commit message contains `ci skip`, `skip ci`, or `skip gha`
ENCLOSED WITH BRACKETS (excluding lint job).
* Separate build and test. This is because builds can be run in parallel,
but running tests in parallel can cause logs to get mixed up or not
finished.
* Don't use Chocolatey because it seems to take 1-2 minutes to start up.
* Use the cache better.
* Use `actions/checkout@v2` instead of `actions/checkout@v1`.
* Remove unnecessary package installation.
* Remove unnecessary flag settings.
* Remove `-j` for rake because it doesn't seem to have any effect.
* Rename `main.yml` to `oss-fuzz.yml` to clarify.
Currently, there are build configuration files for CI, `travis.rb` and
`appveyor.rb`, but they are used for GCC/Clang and MSVC, not for Travis CI
and Appveyor, respectively.
Therefore, rename them to `gcc-clang.rb` and `msvc.rb`, respectively, and
move them under `build_config/ci/` to clarify that they are for CI.
I tried `$GITHUB_PATH` and `$GITHUB_ENV` instead of `set-env`, but
for some reason path was not recognized, so I changed to using
`ACTIONS_ALLOW_UNSECURE_COMMANDS`.
* In explanation of mruby, the expression `build_config.rb` is frequently
used including official documents, so I think that it will not make sense
if the file is no longer used.
* The `MRUBY_TARGET` mechanism seems to have little improvement, so I don't
think it should be changed to avoid unnecessary confusion.
* `MRUBY_TARGET` and `MRuby.targets` represent somewhat different things,
so using the same term "target" is a bit confusing.
The mechanism that can be written short when using a file under
`build_config` (renamed from `target`) directory remains
(`build_config/${MRUBY_CONFIG}.rb` is used if the path specified
in `MRUBY_CONFIG` doesn't exist).
Yukihiro "Matz" Matsumoto