PR #1517 (Jun 2024) simplified codeql.yml in ways that left scans
incomplete: it dropped the actions:read / contents:read permissions and
the analyze category, both of which CodeQL Action requires for results
to land under the existing language category. Combined with the later
cpp -> c-cpp rename and v3 -> v4 upgrade, scheduled scans have not
refreshed the Security tab since Jun 1, 2024.
- Add actions:read and contents:read back to job permissions
- Set build-mode: manual on init (required for v3+/v4 manual builds)
- Pass category "/language:c-cpp" on analyze so SARIF de-duplicates
against the configured language
- Build with --parallel so the tracer keeps up on default runners
## Summary
Introduces an opt-in unit test layer for coturn using
[Unity](https://github.com/ThrowTheSwitch/Unity) — a single-header
pure-C test framework that matches coturn's C11 toolchain, portability
bar, and zero-C++ production tree.
- Unity v2.6.0 is fetched on demand via CMake `FetchContent` (nothing
vendored).
- Tests are gated behind `-DBUILD_TESTING=ON` (off by default), so the
standard build and OSS-Fuzz pipeline are unaffected.
- Two test binaries cover pure C-callable code in `libturnclient`:
- `test_ioaddr` (6 cases) — `make_ioa_addr`,
`addr_get_port`/`addr_set_port`, `addr_eq` variants, `addr_to_string`,
IPv4/IPv6/garbage input
- `test_stun_msg` (7 cases) — STUN header construction,
request/indication/success/error response classification, transaction-ID
round-trip, channel message parsing, truncated/zeroed buffer rejection
- New `check` cmake target builds tests before running ctest (avoids the
`make test` footgun where the auto-generated `test` target only runs
already-built binaries).
- Legacy `Makefile.in` gets a `unit-tests` target that bootstraps
`build/unit-tests/` and delegates to the cmake `check` target. `make
check` and `make test` now run the RFC 5769 conformance suite **plus**
the Unity unit tests.
- CLAUDE.md documents the new workflow plus the one-liner for adding a
new `test_<name>.c`.
## Why
The existing test story is shell-script integration suites under
`examples/scripts/` — they exercise the binary end-to-end but can't pin
down behavior of individual functions, can't run without a full build
environment, and don't fail loudly when a unit-level invariant breaks. A
lightweight unit layer gives us:
- Targeted regression coverage for protocol parsing/encoding (the
highest bug-yield area).
- A natural home for tests of the kinds of subtle invariants already
documented in CLAUDE.md (port-counter overflow safety, port-bounds
inclusivity, HMAC buffer initialization).
- Sub-second feedback for contributors.
## Usage
```bash
# CMake direct
cmake -S . -B build -DBUILD_TESTING=ON
cmake --build build -j --target check # build + run all unit tests
ctest --test-dir build --output-on-failure # run already-built tests
# Legacy Makefile bridge (after ./configure)
make unit-tests # bootstraps build/unit-tests/, builds + runs Unity tests
make check # RFC 5769 conformance + unit tests
```
Adding a new test:
1. Drop `tests/test_<name>.c`
2. Append `coturn_add_test(test_<name>)` in `tests/CMakeLists.txt`
3. The `check` target picks it up automatically.
## Test plan
- [x] Clean cmake build with `-DBUILD_TESTING=ON` succeeds; full source
tree (turnserver, turnadmin, turnclient, turn_server, all turnutils)
still builds
- [x] `cmake --build build --target check` builds and runs both test
binaries — 13/13 cases pass
- [x] `ctest --verbose` shows per-case PASS lines for all 13 cases
- [x] Default build (`-DBUILD_TESTING` unset) does not fetch Unity or
build any test binary
## Notes for reviewers
- Why Unity over GoogleTest/Catch2: pure C, single source file, no C++
toolchain dependency, runs anywhere coturn does (incl. exotic CMake
targets like Solaris/AIX). GoogleTest would force `extern "C"` wrappers
and a C++ compiler everywhere.
Small fixes across CI workflows and test scripts:
- In examples/run_tests.sh & examples/run_tests_conf.sh: ensure both
turnserver and the turnutils_peer background process are killed at the
end
- cmake.yml so binaries end up in the expected folder
- linux.yml - add install so that binaries are in the expected folder
Additionally:
- fix missing NSIS for Windows on CI
- replace macOS 13 with 26 on CI
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Kai Ren <tyranron@gmail.com>
allow fuzzing to be performed as part of the continuous integration.
the timing of the fuzzing can be extended, and i aim to broaden the
scope of the fuzz testing as well, since we currently only test the stun
message parser.
rebase and refactor of [this
pr](https://github.com/coturn/coturn/pull/1400) from last year that was
never merged
rename of cmake YAML file to match others and extraction of dependencies
to already existing composite action
- libsystemd does not exist on macOS - ignore it and reduce warnings
during cmake step
- mongo-c has cmake file on macOS - reusing the same code path and
reduce warnings
Openssl 1.1.1 is end-of-life in September 2023.
This PR removes support for versions of openssl OLDER than 1.1.1
1.1.1 should still be usable after this change is merged.
I don't see any value in supporting 1.1.1, but didn't see a reason to
purge support for 1.1.1 when there are so few checks for >= 3.0.
Note that this does also remove CI support for Ubuntu 16.04. The
official version of OpenSSL from Ubuntu for this release is listed here:
https://launchpad.net/ubuntu/+source/openssl as 1.0.2g
Since no newer releases of coturn will be backported by Canonical to
Ubuntu 16.04, anyone using Coturn on this operating system will have to
download and compile it themselves. They may build their own version of
OpenSSL if they somehow cannot upgrade to a newer version of Ubuntu.
My position is that these users should prefer to upgrade to a newer
operating system than worry about chasing newer releases of Coturn.
Co-authored-by: Pavel Punsky <eakraly@users.noreply.github.com>
Some actions do not build with prometheus - adding prometheus tests
fails the jobs
cmake build tests did not run due to different target folder (while
reporting success) - now the bin folder is detected
Implement a custom prometheus http handler in order to:
1. Support listening on a specified address as opposed to any
2. Remove the requirement on the unmaintained promhttp library
This feature comes with one limitation: if an IPv4 address is used, the
server will not listen on the IPv6-mapped address, even if IPv6 is
available. That is, dual-stacking does not work.
Solves: #1475
---------
Co-authored-by: Pavel Punsky <eakraly@users.noreply.github.com>
In preparation to deprecation of openssl below version 1.1.1 switch to
using openssl-1.1.1 on amazonlinux:2 (where 1.0.2 is the default)
Fixes build issue for #1397
This problem is caused by this issue:
https://github.com/actions/checkout/issues/1809
Several comments include documentation on various environment variables
to force it to use the older nodejs release still, but probably those
various workarounds will stop working eventually.
Fixes#1533 and #1534
Memsetting `turn_params.default_users_db` before reading conf file, not
after.
Because auth is read in first iteration so secret was wiped out.
# test plan
Add new test script that uses config file to setup turnserver instead of
cli arguments and confirm it works (fails without the change)
Use the include-what-you-use program to (partially) clean up header
includes, so that only includes which are needed, and no includes that
are not needed (or at least closer to that ideal) are done.
For a c-language project, the build-time improvements from this change
is minimal. This would have a much bigger impact on a C++ project than a
C-project for build times.
So for coturn, this change is mostly intended to just provide
consistency and make it easier to locate weird issues like strange
dependencies, and unnecessary connections between code.
I'm having trouble testing changes in my own fork because many of the CI
workflows are only set to build on a pull request.
Better to just build on any commit.
I've left the docker builds as they are.
Someone working on a branch in their own fork won't see the lint running
on their github-actions CI until they open a pull request.
It'd be much easier to ensure changes being worked on are going to pass
the linter if the linter runs before the last step of opening the PR.
Pavel Punsky
dependabot[bot]
redraincatching
Kai Ren
Michael Jones
Alex Gustafsson