ci: run the tests again - #231
Merged
Merged
Conversation
CI went out with the SaaS platform in #161 and never came back, so the whole LGPL migration and the player work were tested only on whichever machine a developer was sitting at. Nothing was disabled — the directory was deleted — and Actions has been enabled on the repository throughout. The old workflow would not have run today: it matrixed over `hls` and `segment-editor`, which #187 renamed and folded in, and knew nothing of the three player workspaces. It now covers the eight workspaces that have suites, and asserts the five libraries emit their declarations, which is exactly how bccsa/luminary consumes them through the submodule. Only tests and a clean-checkout build. The workflows that produce binaries — ffmpeg-build, windows-installer — stay out: those carry the distribution question the patent position rests on, and reinstating them is not a decision to make in passing. Verified locally by running each job's steps from a clean checkout: build:libs, build:bundled, the declaration check, and all eight suites — api 1179, app 481, player-core 193, hls-core 134, player-web 96, player-web-legacy 93, encode-config 60, app-electron 16.
johan-bell
added a commit
that referenced
this pull request
Sep 3, 2026
…232) * ci: one workflows directory, and make the four that were parked run CI was switched off in #161 by renaming .github to .github.disabled. I read that as deletion and wrote a fresh tests.yml in #231, so the repository ended up with both — two tests.yml, one current and one that would fail on its first run. Everything now lives in .github/workflows. The parked tests.yml goes: it matrixes over hls and segment-editor, which #187 renamed and folded in, and knows nothing of the three player workspaces. The other four move across, and none of them ran as they stood: ffmpeg-build asserted libx264 was present in the shipped binary and encoded its test media with it — the opposite of what this build is. It now refuses a binary that *has* libx264, checks the banner reports Lesser, and encodes through h264_videotoolbox on macOS. The Windows verifier writes no H.264 at all: that runner has no GPU and the build has no software encoder, so every route is absent by design. It proves what it can — the filter chain, libwebp, the waveform path — and says why the rest is answered on real hardware. pinned-binaries-health pointed at electron/scripts, renamed in #187. Its script was stale too: check-pinned-urls.mjs still required X264_REPO in versions.sh, which the LGPL build removed, so it exited non-zero before checking anything. With the x264 pin dropped it passes — FFmpeg 8.1 and its signature, libwebp, nv-codec-headers, libvpl all reachable. download-metrics was two major versions behind on its actions. Verified: all five parse; check-pinned-urls passes; build:libs and the app-electron suite still green. * ci: do not recompile FFmpeg three ways for a workflow edit The push trigger had no branch filter and listed its own file among the paths. So a feature branch touching a pin rebuilt every target on every push — and merging the previous commit, which edits this workflow, would itself have started a full three-target build for a change that only corrected the libx264 assertions. Now: main only, on ffmpeg-build/** alone. Editing the checks is not a reason to recompile FFmpeg; dispatch a run by hand when it is. * ci: the installer upload pointed at the old electron/ path package:win writes to app-electron/release, renamed in #187. The upload step still named electron/release/*.exe, so the job would have run the whole cross-build and packaging and then failed on if-no-files-found — with the installer sitting on the runner, unreachable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was actually wrong
The workflows were not disabled — the
.githubdirectory was deleted, when the SaaS platform was removed in #161. Actions has been enabled on the repository the whole time; there was simply nothing to run. So this is a restore, not a switch.Consequence: the entire LGPL migration and the player work were tested only on whichever machine a developer happened to be sitting at.
Why the old one couldn't just be restored
It matrixed over
hlsandsegment-editor— renamed and folded in by #187 — and knew nothing ofplayer-core,player-weborplayer-web-legacy. Restored verbatim it would have failed on its first run.It now covers the eight workspaces that have suites, and keeps the declaration check pointed at the five libraries, which is exactly how
bccsa/luminaryconsumes them through the submodule: a library that emits JS but no.d.tsbreaks its consumer rather than itself. That matters more than it used to — Luminary's CI now builds these packages, so a break here surfaces over there with nothing to point at.Verified before proposing
I ran each job's steps from a clean checkout rather than trusting the YAML:
npm ci→build:libs→build:bundled— all cleanELECTRON_SKIP_BINARY_DOWNLOAD=1is kept: nothing here launches Electron (app-electron's suites cover pure helpers), and that download was the single most common cause of an unrelated red run.Deliberately not included
ffmpeg-build.ymlandwindows-installer.yml, which produce binaries. The #200 squash message records that CI was off "as instructed", with a note about the release download counts the patent position rests on — that is a decision someone made on purpose, and reinstating artifact-producing CI is not something to slip into a test-restore PR. Worth a separate conversation with whoever gave that instruction.