ci: statically link MinGW runtimes in Windows GUI builds#204
Merged
Conversation
When Postie processes a watched folder (SingleNzbPerFolder or explicit folder upload), generated NZB and PAR2 files are now placed inside a dedicated <outputDir>/<folderName>/ subdirectory instead of directly in the output root. Before this fix, postFolder() used: nzbPath = filepath.Join(outputDir, folderName+".nzb") par2OutputDir = outputDir Both paths now use folderOutputDir = filepath.Join(outputDir, folderName), so the layout becomes: <outputDir>/Movie_A/Movie_A.nzb <outputDir>/Movie_A/*.par2 (when maintain_par2_files=true) This fixes the cross-volume case (watch folder and output folder on different mount points) where files were previously scattered in the output root. The fix covers both the sequential (WaitForPar2=true) and parallel (WaitForPar2=false) code paths. Also bumps Node.js to v22 in CI workflows and adds tests covering: - Sequential and parallel paths with maintain_par2_files=false - Sequential and parallel paths with maintain_par2_files=true (peer files) - Explicit cross-volume path separation scenario
Bump docker/setup-buildx-action v3→v4, docker/login-action v3→v4, docker/build-push-action v5→v6, docker/metadata-action v5→v6, and Zig compiler 0.14.1→0.15.1 across dev-build.yml and release.yml.
ubuntu-latest (Ubuntu 24.04) installs chromium-browser as a snap wrapper which fails in CI due to snap store timeouts. The GitHub Actions runner already ships google-chrome-stable, which the e2e helpers already prefer as the first candidate.
…ration race
openSettingsTab was using WaitReady(body)+Sleep(300ms) before clicking
the target tab. In CI, the Svelte config fetch + {#if enabled} render
cycle can exceed 300ms, leaving the tab-panel content un-rendered when
WaitVisible polls for elements inside it.
Replace the fixed sleep with WaitVisible(tabSelector) which blocks
until the page has fully hydrated and the tab input itself is in the
DOM — a reliable signal that all tab-panel content is rendered.
The Windows GUI (Wails) build was missing MSYS2 setup and CGO_LDFLAGS, causing the executable to depend on libgcc_s_seh-1.dll, libstdc++-6.dll, and libwinpthread-1.dll at runtime. Add the same static linking flags already used by the CLI build to both release.yml and dev-build.yml. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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
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.
Summary
mingw-w64-x86_64-gccto the Windows GUI build jobs in bothrelease.ymlanddev-build.ymlCCandCGO_LDFLAGSenvironment variables to statically linklibgcc,libstdc++, andlibpthread— matching the CLI build configurationlibgcc_s_seh-1.dll,libstdc++-6.dll, andlibwinpthread-1.dllalongside the Windows GUI executableTest plan
dev-buildworkflow passespostie-gui-windows-amd64artifactdumpbin /dependents postie.exethat no MinGW DLLs are referenced🤖 Generated with Claude Code