Files
obs-streamer-tools-plugin/.gitea/workflows/build.yml
T
shadowdaoandClaude Sonnet 5 79de5e8f23
Build / macOS (macos-latest) (push) Successful in 32s
Build / Linux (ubuntu-24.04) (push) Successful in 46s
Build / Windows (windows-latest) (push) Failing after 9m20s
Fix Windows find_package(libobs) and make CI hard-fail when the OBS module is missing
Root cause of the find_package(libobs) failure on Windows: OBS's own
modern-CMake Windows layout (obs-studio/cmake/windows/defaults.cmake sets
OBS_CMAKE_DESTINATION=cmake) installs libobs's CMake package config to
<prefix>/cmake/libobs/ -- a shape find_package(libobs CONFIG) never
searches under CMAKE_PREFIX_PATH. Verified empirically with
--debug-find-pkg=libobs: CMake's Config-mode search suffixes try
<prefix>/cmake/libobsConfig.cmake (no <name> subdirectory) and
<prefix>/libobs*/cmake/... (a <name>-prefixed dir first), never
<prefix>/cmake/<name>*/. This has nothing to do with the earlier "file
INSTALL cannot find obs-frontend-api.dll" error the bootstrap already
tolerates -- libobs is the first subdirectory obs-studio's modern
top-level CMakeLists.txt adds (well before UI), so libobs's own
install(EXPORT ...) rules already completed by the time that later,
unrelated install error aborts the script. macOS is unaffected
(OBS_CMAKE_DESTINATION=lib/cmake there, matching the standard
<prefix>/lib*/cmake/<name>*/ suffix), and so is Linux's libobs-dev
(/usr/lib/<arch>/cmake/libobs/, same standard suffix).

Fix: point libobs_DIR directly at the from-source Windows install when it
exists, bypassing find_package's path-search heuristics entirely. Also
fixed a secondary bug found while tracing this: the existing WIN32
locationless-OBS::libobs repair looked for obs.dll under
"<deps>/bin" instead of the actual OBS_EXECUTABLE_DESTINATION,
"<deps>/bin/64bit".

Also make the Windows and macOS "Show what was built" CI steps hard-fail
when the OBS adapter module is missing, instead of only printing a
message. Several recent "green" Windows runs silently shipped a
core-library-only build because of the bug above; nothing in CI caught
it, only a human reading the raw log by hand. Left Linux untouched (its
check is already a hard, non-"|| true" verification). Applied the same
hard-fail treatment to macOS: its bootstrap has been reliably building
the real module in CI (6/6 tests, per README), so there's no longer a
known legitimate reason for a silent core-only fallback there either --
the documented macOS packaging/bundle-loadability gap is a separate,
already-visible issue this check doesn't touch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
2026-09-07 04:53:03 -07:00

195 lines
8.6 KiB
YAML

name: Build
# Every job builds the real plugin: the core library linked against the
# pinned livekit/client-sdk-cpp release, and -- where libobs is available --
# the OBS adapter module itself.
#
# Linux gets libobs from Ubuntu's libobs-dev. macOS and Windows have no
# equivalent system package, so they run obs-plugintemplate's buildspec
# bootstrap (buildspec.json + cmake/common/buildspec_common.cmake), which
# downloads the pinned obs-deps bundle and obs-studio source and builds just
# `libobs`. That step is the slow one: several minutes on a cold runner.
#
# RELEASE GATE: this workflow only builds, tests, and uploads CI-internal
# workflow artifacts (actions/upload-artifact, below) -- it does not create a
# Gitea Release, push a tag-triggered publish, or otherwise distribute
# binaries publicly, and it must not start doing so without explicit owner
# sign-off on the WebRTC/OpenH264 attribution question tracked in
# third_party/livekit/README.md and the README's top-level Status section.
# (The separate GPLv2/Apache-2.0 license-compatibility question is resolved:
# this project's own code is Apache-2.0.) If a real release/publish step is
# ever added here, it must carry that same gate.
on:
push:
pull_request:
jobs:
linux:
name: Linux (ubuntu-24.04)
# Pinned to 24.04 rather than ubuntu-latest, which this instance's two
# Linux runners answer with different releases. 24.04's libobs-dev is
# 30.0.2, exactly the OBS version buildspec.json pins for macOS/Windows,
# so all three platforms build against the same libobs. On a 22.04 runner
# libobs-dev is OBS 27, which is a different API surface entirely.
runs-on: ubuntu-24.04
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install build dependencies
run: |
sudo apt-get update -qq
sudo apt-get install -y -qq cmake ninja-build libobs-dev libcurl4-openssl-dev
- name: Configure
# Linux keeps its distribution libobs; the buildspec bootstrap is for
# the two platforms that have no such package.
run: cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DSTPLUGIN_BOOTSTRAP_OBS=OFF
- name: Build
run: cmake --build build
- name: Test (core library)
run: ctest --test-dir build --output-on-failure
- name: Show what was built
run: |
ls -la build/package/bin/64bit build/package/data/locale build/package/licenses
ldd build/package/bin/64bit/streamer-tools-camera.so | grep -E 'obs|livekit'
nm -D build/package/bin/64bit/streamer-tools-camera.so | grep -E ' T obs_module_(load|unload)'
- name: Upload plugin
continue-on-error: true
uses: actions/upload-artifact@v3
with:
name: streamer-tools-camera-linux-x64
path: build/package
macos:
name: macOS (macos-latest)
runs-on: macos-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install build dependencies
run: brew install cmake ninja
- name: Configure
# The buildspec bootstrap runs here: it fetches obs-deps + the pinned
# obs-studio source and builds libobs before this project configures.
#
# If that fails, fall back to a core-library-only build rather than
# going red: the core library and its tests are what this job mainly
# guards, and the fallback is loud (a workflow warning, plus the
# "Show what was built" step below reporting no module) rather than
# silent. Do not remove the warning -- a green job that quietly stopped
# building the plugin is worse than a red one.
run: |
if ! cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release; then
echo "::warning::OBS SDK bootstrap failed on macOS; building the core library only. The plugin module was NOT built."
rm -rf build
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DSTPLUGIN_BOOTSTRAP_OBS=OFF
fi
- name: Build
run: cmake --build build
- name: Test (core library)
run: ctest --test-dir build --output-on-failure
- name: Show what was built
# This used to be informational only (every command "|| true"'d), so
# a bootstrap failure that silently fell back to a core-library-only
# build still reported a green job -- exactly the false-positive
# class of bug this step exists to catch, caught instead by a human
# reading the raw log by hand. The macOS bootstrap has been reliably
# building the real module in CI (6/6 tests, artifact uploaded --
# see README), so a missing module here is a regression to fail
# loudly on, not the old silent fallback. (This is separate from the
# macOS packaging gap in README -- that the module doesn't yet load
# as an OBS.app bundle -- which this check does not and cannot test.)
run: |
ls -la .deps/Frameworks/libobs.framework/Resources/cmake || true
if [ ! -f build/package/bin/streamer-tools-camera.so ]; then
echo "::error::no plugin module was built -- build/package/bin/streamer-tools-camera.so is missing. The macOS from-source libobs bootstrap is expected to succeed; treat this as a build failure, not a core-library-only fallback."
exit 1
fi
ls -la build/package/bin
otool -L build/package/bin/streamer-tools-camera.so
otool -L build/package/bin/streamer-tools-camera.so | grep -E 'obs|livekit'
- name: Upload plugin
continue-on-error: true
uses: actions/upload-artifact@v3
with:
name: streamer-tools-camera-macos
path: build/package
windows:
name: Windows (windows-latest)
runs-on: windows-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install build dependencies
# winvm-builder is a self-hosted act_runner labeled "windows-latest";
# it is NOT the GitHub-hosted image, so none of that image's
# preinstalled tooling (cmake included) can be assumed present.
uses: lukka/get-cmake@latest
- name: Configure
# The default Visual Studio generator is required, not Ninja:
# cmake/windows/buildspec.cmake keys the dependency slice off
# CMAKE_VS_PLATFORM_NAME, which only a VS generator sets.
#
# Same fallback as macOS, and the same warning: a green job that
# quietly stopped building the plugin is worse than a red one.
# PowerShell, not bash: this runner is a plain Windows VM and bash
# cannot be assumed present.
run: |
cmake -S . -B build -A x64
if ($LASTEXITCODE -ne 0) {
Write-Host "::warning::OBS SDK bootstrap failed on Windows; building the core library only. The plugin module was NOT built."
Remove-Item -Recurse -Force build -ErrorAction SilentlyContinue
cmake -S . -B build -A x64 -DSTPLUGIN_BOOTSTRAP_OBS=OFF
if ($LASTEXITCODE -ne 0) { exit 1 }
}
- name: Build
run: cmake --build build --config Release
- name: Test (core library)
run: ctest --test-dir build -C Release --output-on-failure
- name: Show what was built
# This used to be informational only: the else branch printed a
# message and exited 0, so a bootstrap failure that silently fell
# back to a core-library-only build (or a find_package(libobs)
# failure after a libobs that genuinely built, per the
# find_package(libobs) CMakeLists.txt fix above) still reported a
# green job -- exactly the false-positive class of bug this step
# exists to catch, caught instead by a human reading the raw log by
# hand across several "green" runs. The from-source libobs bootstrap
# is now expected to work reliably on this runner (that is the whole
# point of the buildspec bootstrap + find_package fix), so a missing
# module here is a regression to fail loudly on, not the old silent
# fallback.
run: |
$module = "build\package\bin\64bit\streamer-tools-camera.dll"
if (Test-Path $module) {
Get-ChildItem build\package\bin\64bit
} else {
Write-Host "::error::no plugin module was built -- $module is missing. The Windows from-source libobs bootstrap is expected to succeed; treat this as a build failure, not a core-library-only fallback."
exit 1
}
- name: Upload plugin
continue-on-error: true
uses: actions/upload-artifact@v3
with:
name: streamer-tools-camera-windows-x64
path: build/package