- explicitly install `libldap-dev` to not rely on test-specific packages
installing it implicitly, to have the same `curl -V` output for each
TLS backend build pair.
Follow-up to 0455d8772a#18509
- install `libev-dev` for tests. It's a runtime dependency for
the local build of `nghttpx`. Missing it made pytest skip 178 tests.
Also skewing the 'Gain' time. I estimate it to account for 3 minutes,
making the total gain ~20 minutes.
Follow-up to 0455d8772a#18509
(It may be a better solution to disable libev for the local nghttp2
build, to avoid this hidden dependency.)
- fix quiche jobs to use the local build of `libnghttp2`.
- stop installing the `clang` package for Windows-cross. `clang` and
`clang-tidy` tools are preinstalled on the Ubuntu 24.04 runner.
Closes#18519
In the last couple of months some jobs started taking a lot of time and
often timing out due to slow `apt install` from the Azure Ubuntu mirror.
The jobs affected were those that installed large packages:
GHA/http3-linux and the 3 cross-build jobs in GHA/windows.
This patch reduces the installed packaged to the minimum required
to complete the jobs. Saving a minute+ for each http3-linux job (a total
of 20+ minutes for the workflow.) Also saving bandwidth and reducing
the chance for long downloads or timeouts with slow Azure repos.
Details:
- http3: delete redundant packages from the `build-cache` job.
- http3: install gnutls dependencies for gnutls jobs only.
- http3: do not install test dependencies in jobs not running tests.
- http3: drop redundant packages from the curl jobs.
- Windows-cross: replace `mingw-w64` with `gcc-mingw-w64-x86-64-win32`
for the 3 Windows cross-build job. Dropping C++, 32-bit, and 64-bit
POSIX-threaded parts. Saving time and significant bandwidth for each
of the 3 jobs:
Download size: 277 MB -> 65 MB (installed: 1300 MB -> 400 MB)
- Windows-cross: restore previous job time limit of 15m (from 45m)
Follow-up to ff5140a25f#18163
Before:
https://github.com/curl/curl/actions/runs/17611514207 (http3)
https://github.com/curl/curl/actions/runs/17611514185/job/50034354923 (Windows cross)
After:
https://github.com/curl/curl/actions/runs/17628406362?pr=18509 (http3)
https://github.com/curl/curl/actions/runs/17627562551/job/50088055529?pr=18509 (Windows cross)
http3 job | Bef. | Aft. |
:------------------ | ------: | ------: |
Build caches (hot) | 10s | 12s |
AM awslc | 3m 0s | 1m 54s |
CM awslc | 4m 32s | 3m 4s |
AM boringssl | 3m 9s | 1m 48s |
CM boringssl | 3m 43s | 3m 2s |
AM gnutls | 3m 9s | 2m 18s |
CM gnutls | 4m 19s | 2m 55s |
AM libressl | 2m 14s | 1m 24s |
CM libressl | 5m 30s | 2m 57s |
AM openssl | 5m 16s | 4m 17s |
CM openssl | 1m 50s | 1m 47s |
AM openssl-quic | 2m 58s | 1m 7s |
CM openssl-quic | 4m 16s | 2m 43s |
AM quiche | 2m 54s | 1m 34s |
CM quiche | 5m 0s | 3m 15s |
AM quictls | 2m 34s | 1m 13s |
CM quictls | 4m 20s | 3m 17s |
AM wolfssl | 2m 48s | 1m 30s |
CM wolfssl | 4m 49s | 3m 22s |
Total: | 66m 21s | 43m 27s |
Gain: | | 22m 54s |
Out of curiousity, build times as seen in the http3 build-cache job:
- TLS backends:
- openssl: 2m25s
- libressl: 27s
- aws-lc: 41s
- boringssl: 1m8s
- quictls: 1m46s
- gnutls: 6m30s
- wolfssl: 51s
- quiche + boringssl: 1m9s
- ng* libs (not yet optimized for build speed):
- nghttp3: 13s
- ngtcp2: 52s (with 6 backends, 3 runs)
- ngtcp2: 19s (boringssl)
- nghttp2: 21s
Ref: https://github.com/curl/curl/actions/runs/17626120054/job/50083344805
A similar effort in curl-for-win, affecting 2 GHA/curl-for-win Windows
jobs (though they use the default Debian repo, with no issues):
- with llvm/clang:
Download size: 648 MB -> 430 MB (installed: 3344 MB -> 2333 MB)
- with gcc:
Download size: 550 MB -> 328 MB (installed: 2815 MB -> 1804 MB)
Ref: e19665d948
Ref: 6b14c3946a
Bug: https://github.com/curl/curl/pull/18502#issuecomment-3270259744Closes#18509
Perl got bumped from 5.38.4 to 5.40.3. The new version crashes when
loading the `Win32::Process*` modules built and cached in CI. The build
job uses Perl 5.38.4.
To avoid the crash, include the Perl version (hashed) in the cache key,
so that it's only loaded when the Perl version matches.
This solution is imperfect, because some of the jobs will not use the
Perl modules in transition periods, when different jobs use different
Perl versions. Anyway, can't think of a better one for now. Another
option is to drop the effort with these modules. After all they did not
help with crashes and hangs, nor with performance. While adding quite
a bit of CI complexity.
Also:
- test early if the modules load and log the result.
Follow-up to 52775a7fb4#18296Closes#18425
To make the CI jobs use native Win32 API calls instead of calling
external tools to look up and kill PIDs of native Windows test server
processes.
Follow-up to 2388b0e587#18308Closes#18296
This patch fixes flakiness caused by MSBuild scanning the runtests.pl
output for regex patterns. When finding a hit, it returns an error code
to cmake, making the build test CI step fail. This happens rarely after
an earlier mitigation tweaking outputs, but, as expected, it did not
resolve it completely.
MSBuild doesn't have an option to disable this behavior. To fix, this
patch migrates the two affected jobs from MSBuild to Ninja. To align
with existing multi-config logic, it uses the `Ninja Multi-Config`
generator, which hasn't been tested before in CI.
Switching to Ninja was not trivial. Visual Studio to this day relies on
an MS-DOS batch file stored at an unstable location (containing spaces
and parenthesis), to initialize its environment. Without this env,
`cl.exe` is unable to find its own components. GHA does not initialize
it (even if it did, it could only default to a single specific target).
CMake helps with this when using a Visual Studio generator, but doesn't
when using Ninja. (On local machines the VS installer adds a couple
of Start menu items for launching pre-configured command prompts.)
Ref: https://learn.microsoft.com/cpp/build/building-on-the-command-line
The MS-DOS batches don't integrate well with CI envs and even less so
with shell scripts. To avoid it, this patch uses manual configuration.
Also without using environment variables, to make it easy to use and
easy to debug and trace in logs. Configuring Visual Studio is relatively
stable across releases and hasn't changed a whole lot in the last 2
decades, but still may need more maintenance compared to llvm, or pretty
much any other toolchain out there. On the upside, it allows to manually
select compiler version, SDK version, cross-combinations, and allows
choosing clang-cl. The configuration aims to find the latest of these
automatically.
Some traps that had to be avoided:
- need to switch to MS-DOS short names to avoid spaces in the VS
component paths.
- need to switch to forward slashes to avoid confusing downstream tools
with backslashes.
- need to pass either MSYS2 for Windows-style path depending on setting.
- need to use a trick to retrieve the oddly named `ProgramFiles(x86)`
Windows env from shell script.
- need to match VS version (2022) and edition (Enterprise), found on GHA
runners.
- need to pass the CMake generator via env so that the space in the name
doesn't trip the shell when passed via a variable.
- trash and unexpected dirs when detecting SDK/toolchain versions.
- need to pass `-external:W0` to the C compiler to avoid MSVC warning:
`D9007: '/external:I' requires '/external:W'; option ignored`
- using cmake options only, to make it run without relying on envs and
work out-of-the-box when running subsequent cmake sessions.
- some others discovered while making work clang-cl locally in
cross-builds.
Ninja also improves performance in most cases (though wasn't a goal
here). After this patch configure is significantly faster (1.5-2x),
builds are a tiny bit faster, except examples which was twice as fast
with MSBuild. Disk space use is 10% lower.
MSBuild builds remain tested in AppVeyor CI and the UWP job.
Before: https://github.com/curl/curl/actions/runs/17025737223/job/48260856051
After: https://github.com/curl/curl/actions/runs/17027981486/job/48266133301
Fixes:
```
=== Start of file stderr1635
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 4 100 4 0 0 449 0 --:--:-- --:--:-- --:--:-- 500
curl : (22) The requested URL returned error : 429 [D:\a\curl\curl\bld\tests\test-ci.vcxproj]
CUSTOMBUILD : warning : Problem : HTTP error. Will retry in 1 second. 1 retry left. [D:\a\curl\curl\bld\tests\test-ci.vcxproj]
[...]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'D:\a\curl\curl\bld\CMakeFiles\621f80ddbb0fa48179f056ca77842ff0\test-ci.rule;D:\a\curl\curl\tests\CMakeLists.txt' exited with code -1. [D:\a\curl\curl\bld\tests\test-ci.vcxproj]
Error: Process completed with exit code 1.
```
Ref: https://github.com/curl/curl/actions/runs/16966304797/job/48091058271?pr=18287#step:13:3471
Bug: https://github.com/curl/curl/discussions/14854#discussioncomment-14104166
Ref: a19bd43210#18307
Follow-up to 9463769f2e#16583Closes#18301
In CI we want to ensure that examples build cleanly, but we don't want
to actually run them there. Meaning it's enough to just compile, but not
link them in CI. Saving time up to 2-4x (MSVC), and disk space up
to 1.2GB (or 8-70x).
Add a new cmake target that compiles all examples without linking them
into runnable binaries. Keep a full build for a single example to test
if it links correctly.
Also:
- CI: switch over all `curl-examples` targets to `curl-examples-build`
- GHA/linux-old: build examples in one of the cmake builds.
Result highlights:
Job | Bef. | Bef. | Aft. | Aft. |
:------------------ | ---: | ----: | ---: |----: |
cygwin | 15s | 9MB | 10s | 1MB |
msys | 13s | 8MB | 7s | 1MB |
dl-mingw 15 | 39s | 113M | 34s | 2MB |
dl-mingw 9.5.0 | 49s | 115MB | 42s | 2MB |
dl-mingw 7.3.0 | 19s | 113MB | 14s | 2MB |
dl-mingw 6.4.0 | 9s | 12MB | 7s | 4MB |
Linux cross | 19s | 28MB | 19s | 2MB |
MSVC UWP | 65s | 374MB | 9s | 17MB |
MSVC x64 | 22s | 846MB | 9s | 17MB |
VS2010 | 48s | 105MB | 15s | 9MB |
VS2022 clang-cl | 195s | 1.2GB | 51s | 20MB |
iOS Xcode | 8s | | 5s | |
macOS LibreSSL | 16s | | 11s | |
Linux aws-lc | 3s | | 1s | |
Follow-up to dda251ef10#18232Closes#18209
Recently sometimes the Ubuntu package repository is very slow to access.
Remove the time limit for the install step, and bump the total limit,
aligning with Linux jobs.
In most cases the `install packages` steps takes 15-25 seconds.
Sometimes this goes up to 30-45 minutes.
Reported-by: nevakrien on github
Bug: https://github.com/curl/curl/discussions/14854#discussioncomment-13988574Closes#18163
Schannel is not supported by UWP. SSPI is also required by Schannel in
curl, and SSPI also isn't supported by UWP.
mingw-w64 is able to create such build regardless (my guess: due to API
parts not accurately marked as UWP-only), but the binary is unlikely
to work. With MSVC the failure happens at build-time.
Ref: https://learn.microsoft.com/windows/win32/api/sspi/nf-sspi-initsecurityinterfacea#requirements
Ref: https://learn.microsoft.com/windows/win32/secauthn/initializesecuritycontext--schannel#requirements
Drop all UWP-related logic, including two related feature checks, that
can now be permanently enabled.
Also:
- build: show fatal error for Schannel in UWP mode.
- build: do not allow enabling SSPI in UWP mode.
- drop undocumented option `DISABLE_SCHANNEL_CLIENT_CERT`. Added without
mention in an unrelated commit. The PR text says to save size. On x64
this is 0.3%, or 4KB out of 1.3MB. The tiny gain doesn't justify
an extra build variant. Ref: 8beff43559
- move `MPROTO_SCHANNEL_CERT_SHARE_KEY` closer to its use.
- replace commented block with `#if 0`.
Reviewed-by: Jay Satiro
Follow-up to cd0ec4784c#17089Closes#18116
libtests and clients were built the same way after recent overhauls.
libtests are used by runtests, clients by pytests.
Merge clients into libtests, aligning their entry function signature,
dropping common utility functions, and simplifying the build.
Note: After this patch `CURLDEBUG` applies to cli tests, when enabled.
Also:
- lib552: drop local copy-paste debug callback in favor of testtrace.
- lib552: drop local copy-paste dump function in favor of testtrace.
- clients: use `long` for HTTP version, drop casts.
- clients: replace local dump function in favor of testrace clone.
- sync cli test entry function prototype with libtests'.
- h2_serverpush: replace local trace callback with testtrace.
- de-duplicate 3 websocket close, ping, ping, functions. Kept the pong
iteration from `ws_pingpong`. Note: the pong clone in `lib2304` was
returning an error when `curl_ws_recv()` returned non-zero and
the payload matched the expected one anyway. After this patch, this
case returns success, as it does in `ws_pingpong`.
`lib2304` keeps passing, but I'm not sure if the previous behavior
was intentional.
- display full value in websocket close, ping, pong, drop casts.
Closes#18079
- GHA/windows: disable building certs in the MSVC job that's not running
tests. Saves 4-5 seconds for MSVC, makes logs shorter for the rests.
- GHA/linux: build tests in two more jobs (LTO, CM Rustls), 5s each.
- GHA/linux: skip 'install test prereqs' for `skiprun` jobs.
(there were no such jobs before this patch.)
Closes#18034
- autotools: fix auto-detection on the Windows platform.
It was mis-detected when targeting Windows XP/2003 64-bit.
It was permanently undetected when building for Windows 32-bit.
```
lib/url.c: In function 'zonefrom_url':
lib/url.c:1802:18: error: implicit declaration of function 'if_nametoindex' [-Wimplicit-function-declaration]
1802 | scopeidx = if_nametoindex(zoneid);
| ^~~~~~~~~~~~~~
lib/url.c:1802:18: error: nested extern declaration of 'if_nametoindex' [-Werror=nested-externs]
```
Ref: https://github.com/curl/curl/actions/runs/16405598782/job/46351023138?pr=17982#step:10:29
Reported-by: LoRd_MuldeR
Fixes#17979
Without this patch the workaround for the 8.15.0 release is:
`export ac_cv_func_if_nametoindex=0` for Windows XP/2003 64-bit.
Background: Checking for the `if_nametoindex()` function via
`AC_CHECK_FUNCS()` (autotools) or `check_function_exists()` (cmake) do
not work on Windows, for two reasons:
- the function may be disabled at compile-time in Windows headers
when targeting old Windows versions (XP or WS2003 in curl context)
via `_WIN32_WINNT`. But it's always present in the system implib
`iphlpapi` where these checks are looking.
- for 32-bit Windows the function signature in the implib requires
a 4-byte argument, while these checks always use no arguments,
making them always fail.
- cmake: call `if_nametoindex` dynamically with mingw-w64 v1.0.
This mingw-w64 version lacks prototype and implib entry for it.
- cmake: add auto-detection for Windows and use as a fallback for
non-pre-fill cases.
- cmake: disable pre-fill with `_CURL_PREFILL=OFF`. (for testing)
- cmake: disable pre-fill for untested compilers. (i.e. non-MSVC,
non-mingw64)
- GHA/windows: make an autotools job build for Windows XP.
Follow-up to 0d71b18153#17413Closes#17982
In preparation for the removal of Windows CE support.
These jobs were also using a macOS runner, which is a waste. And it'd be
too much effort to move them over to Windows or Linux.
Follow-up to 8491e6574c#17379Closes#17924
- circleci: pipe to tar.
- use long options uniformly.
- sync option order.
- set timeout where missing.
- set retry where missing.
- set `--retry-connrefused` where missing.
- set `--disable` where missing.
- lower 999s timeouts to 120s.
Closes#17851
Job `name:` now mandatory in zizmor.
Also:
- enclose `name:` values in single-quotes, for uniformity.
- drop `name: checkout` where set, for uniformity.
- dist: also install with cmake.
- dist: replace `make` with `cmake --build` for cmake.
(to make this make-tool agnostic)
- appveyor-status: double-quote shell arguments.
- tweak existing names to be shorter, to sync terms and style across
jobs and steps.
Ref: https://github.com/zizmorcore/zizmor/releases/tag/v1.10.0Closes#17773
No longer necessary after bumping the default runtime to a version
fixing the previously experienced performance drop.
Thanks to MSYS2/Cygwin teams for the help and fix.
Follow-up to 9a26be1e6a#17708
Follow-up to d4896d94f2#16424Closes#17710
- GHA/windows: make a mingw autotools build static only.
- GHA/windows: fix a CI script issue with the build above.
- src: fix to pass `LIBCURL_PC_LIBS_PRIVATE` instead of `LINKFLAGS`.
This makes the libs propagate to tunits, making the local hack there
unnecessary. `LINKFLAGS` had this single use in the repo, and it was
empty in local tests.
- tests: drop passing redundant `LIBCURL_PC_LDFLAGS_PRIVATE`.
- tests: drop redundant target name from config variables.
- examples, tests/client: drop `LIBDIR` temp variables with single uses.
- examples, tests: formatting to sync `Makefile.am` scripts with each
other.
Closes#17661
To have all the tests binaries directly under the tests directory.
There seems to be no issue adding non-http test clients to this subdir.
Closes#17637
Make test bundles the default. Drop non-bundle build mode.
Also do all the optimizations and tidy-ups this allows, simpler builds,
less bundle exceptions, streamlined build mechanics.
Also rework the init/deinit macro magic for unit tests. The new method
allows using unique init/deinit function names, and calling them with
arguments. This is in turn makes it possible to reduce the use of global
variables.
Note this drop existing build options `-DCURL_TEST_BUNDLES=` from cmake
and `--enable-test-bundles` / `--disable-test-bundles` from autotools.
Also:
- rename test entry functions to have unique names: `test_<testname>`
This removes the last exception that was handled in the generator.
- fix `make dist` to not miss test sources with test bundles enabled.
- sync and merge `tests/mk-bundle.pl` into `scripts/mk-unity.pl`.
- mk-unity.pl: add `--embed` option and use it when `CURL_CLANG_TIDY=ON`
to ensure that `clang-tidy` does not miss external test C sources.
(because `clang-tidy` ignores code that's #included.)
- tests/unit: drop no-op setup/stop functions.
- tests: reduce symbol scopes, global macros, other fixes and tidy-ups.
- tool1621: fix to run, also fix it to pass.
- sockfilt: fix Windows compiler warning in certain unity include order,
by explicitly including `warnless.h`.
Follow-up to 6897aeb105#17468Closes#17590
Extend MSVC jobs with the option to use MSYS2 binary package as DLL
dependencies. Allow to use them alone (without vcpkg) or combined with
vcpkg packages. This saves the trouble of building these packages from
source and cache them manually.
This solution requires two tricks:
- workaround for zlib which installs a target-specific `zconf.h` that's
not portable between platforms and C compilers.
- manual dependency configuration in CMake to ensure linking against
the MSYS2 DLLs (and not it static libs). Static libs aren't portable
to MSVC due to missing symbols `__chkstk_ms`, `_stack_chk_fail`,
`_memcpy_chk`, `_stack_chk_guard`, and potentially other issues. CMake
in MSVC mode, `linker.exe` and `pkg-config` pick the static libs by
default. To pick `.dll.a` in favour of `.a`, these tools would have
to be taught about this convention. An alternative is deleting static
libs and see if `.dll.a` are picked-up automatically.
Using MSYS2 packages adds an install step taking 15-45 seconds per job.
It allowed to:
- re-enable libpsl for all MSVC jobs.
- convert the Intel 64-bit job to use MSYS2 without vcpkg, enabling
brotli, zstd, OpenSSL 3.5.0, libssh2 (with OpenSSL cryprography) and
nghttp2.
Using the same technique it's possible to re-enable more features
in MSVC builds, e.g. GnuTLS (also with H3), LibreSSL, mbedTLS, nghttp3,
ngtcp2, libssh, c-ares, gsasl, and replace vcpkg zlib, for faster runs.
What's missing compared to vcpkg is BoringSSL and wolfSSL
(the MSYS2-supplied build doesn't fit curl's requirements IIRC). These
could be built and cached manually.
Also:
- add workaround for zlib (classic) which uses a generated `zconf.h`,
rendering the MSYS2 zlib header incompatible with MSVC.
- set the correct `msystem` for arm64.
- allow using MSVC without vcpkg.
Follow-up to cd0ec4784c#17089Closes#17561
zizmor 1.9.0 effectively bans using GHA macros within shell script
snippets. Rework them to pass GHA macro values via envs and use those
envs in shell snippets. `${{ env.* }}` macros could be converted
to native env references after making their names shell-compatible.
Envs and shell commands can no longer be used in GHA macro values. Most
cases could be fixed by using literals. Passing quoted values with
spaces combined with other args also doesn't work anymore. This was
replaced by passing them separately.
Despite the initial complications, avoiding GHA macros in scripts does
seems to make the CI code reasonable cleaner. It also makes it possible
to analyze the scripts with shellcheck, finding subtle issues that went
unnoticed till now.
Also:
- un-ignore and fix three existing zizmor `template-injection` issues.
- add script to extract and shellcheck all shell code stored within GHA
and Circle CI YAML files.
- add CI job to run this script.
- fix shellcheck issues discovered.
- fix minor differences between cmake and autotools FreeBSD jobs.
- merge cmake/autotools FreeBSD jobs to avoid developing unwanted
differences again.
- fix/sync quote use across shell code.
- replace `$HOME` with `~` or literal where it made sense.
- replace most `brew --prefix` with literals.
- move all curl install tests to the `curl-install*` prefix.
- add missing curl install tests to cygwin/msys/mingw/*bsd.
- pipe to `tar` instead of storing downloads on disk.
- drop unnecessary `PKG_CONFIG_PATH` when building nghttp3.
Ref: https://github.com/curl/curl/actions/runs/15461461371/job/43523546041
Ref: https://github.com/zizmorcore/zizmor/releases/tag/v1.9.0
Follow-up to e522f47986#17278Closes#17537
To avoid redundant work in CI and to avoid a single checksrc issue make
all autotools jobs fail. After this patch checksrc issues make fail
the checksrc job, the `dist / verify-out-of-tree-autotools-debug`,
`dist / maketgz-and-verify-in-tree` jobs and the fuzzer job (if run).
Of these, the `dist` jobs replicate local builds, also testing the build
logic.
Also add a script to check the complete local repository, optionally
with the build tree to verify generated C files.
Also:
- automatically run checksrc in subdirectories having a `checksrc`
target. (examples, OS400, tests http/client, unit and tunit)
- tests/libtest: make sure to run `checksrc` on generated `lib1521.c`.
(requires in-tree autotools build.)
- tests: run `checksrc` on targets also for non-`DEBUGBUILD`
builds. It ensures to check `lib1521.c` in CI via job
`dist / maketgz-and-verify-in-tree`.
- src: drop redundant `$(builddir)` in autotools builds.
- scripts: add `checksrc-all.sh` script to check all C sources and
the build directory as an option.
- use the above from CI, also make it verify all generated sources.
- silence `checksrc` issues in generated C sources.
- checksrc: add `-v` option to enable verbose mode.
- checksrc: make verbose mode show checked filename and fix to only
return error on failure.
- make sure that generated C files pass `checksrc`.
Assisted-by: Daniel Stenberg
Closes#17376
The pedantic level is experimental. If it causes issues, we may just
disable it alongside the ignore comments.
Also:
- silence error:
```
INFO audit: zizmor: completed label.yml
error[dangerous-triggers]: use of fundamentally insecure workflow trigger
--> label.yml:13:1
|
13 | 'on': [pull_request_target]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ pull_request_target is almost always used insecurely
|
= note: audit confidence -> Medium
```
- fix pedantic warning:
```
INFO audit: zizmor: completed label.yml
warning[excessive-permissions]: overly broad permissions
--> label.yml:1:1
... |
24 | | with:
25 | | repo-token: '${{ secrets.GITHUB_TOKEN }}'
| |____________________________________________________- default permissions used due to no permissions: block
|
= note: audit confidence -> Medium
```
- silence `template-injection` false positives like:
```
- note: ${{ matrix.build.torture && 'test-torture' || 'test-ci' }} may expand into attacker-controllable code
- note: ${{ contains(matrix.build.install_steps, 'pytest') && 'caddy httpd vsftpd' || '' }} may expand into attacker-controllable code
```
It doesn't seem like these could be controlled by an attacker.
Let me know if I'm missing something.
Closes#17278
The unplanned dropping of the granular vcpkg binary cache indeed fell
into the cracks between Microsoft's various departments. The old method
is now official dropped, without replacement either on the vcpkg side or
the GitHub cache provider side.
Without a granular cache, vcpkg is impractical for builds larger than
a small dependency tree in CI, for performance reasons.
A granular cache is critical for CI use. Building dependencies is not
a goal of this CI, so a more desirable option would be pre-built binary
downloads. This would also allow keeping job timeouts low, which is
important for quick iteration in GHA when a flaky job requiring a manual
retry needs all other jobs to finish first. (GHA often disregards
step timeouts, which is another contributing factor here.)
Windows remains tested extensively with MSYS2, curl-for-win, and via
AppVeyor CI with MSVC + OpenSSL, and also in GHA via scaled back vcpkg
jobs that perform well without caching. What's lost is the recently
added Android OpenSSL build tests.
We may consider building/cachine important dependencies manually as in
GHA/linux-http3, and/or try integrating MSVC jobs with MSYS2 UCRT DLLs.
Ref: https://github.com/microsoft/vcpkg-tool/pull/1662
Ref: https://github.com/microsoft/vcpkg/issues/45073
Follow-up to cd0ec4784c#17089
Follow-up to e3912f0f9f#17086
Follow-up to 15fb1dc7f8#17069Closes#17200
This step could take from 5 seconds to 5 minutes, sometimes making it
run out of its time slot. It affected 60 CI jobs.
Saving an estimated minimum of 5 minutes per CI run.
Also fixing:
```
Fri, 25 Apr 2025 06:19:14 GMT
Processing triggers for man-db (2.12.0-4build2) ...
Fri, 25 Apr 2025 06:23:40 GMT
Running kernel seems to be up-to-date.
[...]
Error: The action 'install packages' has timed out after 5 minutes.
```
Ref: https://github.com/curl/curl/actions/runs/14658212268/job/41136971525?pr=17180#step:2:169Closes#17181
They typically finish (well) within 10 minutes.
A notable exception was vcpkg jobs when a rebuild was triggered.
With caching lost and reducing them to short builds, this is not
an issue at the moment.
The advantage of shorter timeouts is hung/crashed jobs giving back
control earlier for a manual retry.
Closes#17173
