make building 'stable' stable - #826
Open
tasty0tomato wants to merge 11 commits into
Open
Conversation
…ails The shell idiom `$MPV_TARBALL && ninja mpv-release || ninja mpv` runs the nightly fallback whenever `ninja mpv-release` fails, not just when MPV_TARBALL is false. Any failure in the stable build path (e.g. mpv master adding a meson option that the current stable tag does not accept) silently produced a nightly build with mpv_ver=UNKNOWN and a green job status, masking real regressions. Replace with explicit if/else so the matrix job fails red when a stable build is requested and `ninja mpv-release` fails.
The stable branch of the packaging script tried to copy `mpv-root/mpv` and `mpv-root/fonts` from shinchiro/mpv-packaging, but those directories no longer exist in that repo. With no `set -e` the `cp` failed silently and stable archives ended up with only `d3dcompiler_43.dll` from the packaging step. End-user impact: stable builds were missing `mpv-install.bat` / `mpv-uninstall.bat` (register mpv as the default media player), `installer/mpv-icon.ico`, `installer/updater.ps1`, `updater.bat`, and `doc/` — all of which the nightly branch correctly bundles via `cp -r mpv-root/*`. Align the stable branch with the nightly one.
Mirror the existing pattern in `packages/mpv.cmake` (line 111) which already calls `force_meson_configure(mpv)`. Avoids stale meson cache when re-running the workflow with different inputs against the same build directory.
Stable tarball artifacts are named mpv-<TAG>-<arch>.7z (version first),
not mpv-<arch>-*.7z (arch first) like nightly builds. The existing upload
glob `mpv-${{ env.arch }}*` only matched arch-first names and silently
dropped all stable artifacts.
Add a second glob `mpv-*-${{ env.arch }}*.7z` to cover version-first
names. The trailing wildcard also handles the x86_64-v3 case where the
arch suffix includes the microarchitecture level (mpv-0.41.0-x86_64-v3.7z).
mpv-release.cmake does not produce a debug symbols package, so the debug upload step emitted a warning for each of the 4 matrix jobs when mpv_tarball=true. Skip the step entirely in that case.
Wrap the existing `meson setup` invocation with a generated bash script that reads the tarball's `meson.options` (or legacy `meson_options.txt`) and drops any `-D<name>=<value>` whose <name> is not declared there. Unknown options are logged to stderr and skipped instead of aborting configure. mpv-release.cmake's option list is kept in sync with mpv master, so building any older stable tag will fail at meson configure as soon as master gains a new option (e.g. `-Dsubrandr=enabled` is unknown to v0.41.0). Combined with the previously fixed silent fallback in the workflow, that turned every stable build request into a nightly build in disguise. The option-name regex is restricted to [a-zA-Z0-9_-]+, matching meson's own grammar, so the filter cannot drop a legitimate flag accidentally or accept arbitrary input from the source tree.
After a successful stable build the workflow runs `rm -rf build_$BIT/mpv*` which removes the mpv-<TAG>-<arch>/ output folder but leaves ExternalProject stamp files inside the toolchain cache. On the next run ninja sees the stamps as up-to-date, skips build/copy-package-dir, and the packaging script finds no directory to archive, causing `mv build/mpv*.7z` to fail. Delete the build and install-chain stamps at cmake configure time so ninja always re-executes those steps. The download stamp is intentionally left intact to avoid re-fetching the tarball.
The build_mpv job checked out ref: master unconditionally, meaning any
cmake/package changes on a non-master branch (e.g. fork-default) were
silently ignored — the cmake files run during the build always came
from master regardless of which branch triggered the workflow.
Change to ref: ${{ github.ref_name }} so the checked-out source matches
the branch that dispatched the workflow.
Stable users expect a fixed version (v0.41.0). Including updater.bat and installer/updater.ps1 would silently upgrade them to nightly, contradicting the reason they chose a stable build. Only copy installer/ and doc/.
tasty0tomato
force-pushed
the
pr/stable-build-fixes
branch
from
May 20, 2026 23:46
67c1ccc to
61ca8c8
Compare
Author
|
https://github.com/tasty0tomato/mpv-winbuild-cmake/actions/runs/26196662127
|
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.
Of course, from mpv's perspective, nightly builds are stable enough. But tagged releases are naturally perceived as "stable" by regular users, and the
mpv_tarballoption inmpv_clanghad several issues that made it unreliable. These fixes make it actually work.btw, I did not do anything about mpv_gcc.