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. # # The actual per-platform dependency-install and configure/build/test/verify # commands live in .gitea/scripts/ and are shared with # .gitea/workflows/release.yml, so the two workflows can't drift apart -- # edit the scripts, not either workflow, to change how a platform builds. # # 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. # # (.gitea/workflows/release.yml is that publish step, gated on a pushed # version tag rather than on every push -- see the gate reminder baked into # its generated release notes.) 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: .gitea/scripts/linux-deps.sh - name: Configure, build, test, verify run: .gitea/scripts/linux-build.sh - 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: .gitea/scripts/macos-deps.sh - name: Configure, build, test, verify run: .gitea/scripts/macos-build.sh - 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, build, test, verify # Windows PowerShell (powershell.exe), not PowerShell Core (pwsh) -- # this self-hosted runner does not have pwsh installed, only the # in-box Windows PowerShell 5.1 the original inline steps implicitly # ran under. shell: powershell run: ./.gitea/scripts/windows-build.ps1 - name: Upload plugin continue-on-error: true uses: actions/upload-artifact@v3 with: name: streamer-tools-camera-windows-x64 path: build/package