4 Commits

Include renames

Author	SHA1	Message	Date
dailzandSisyphus	b96b99fc9c	ci(gitea): install libavfilter dev package ... Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>	2026-07-03 13:10:15 +08:00
dailz	17f5e235a9	ci(gitea): broaden libclang find pattern to match versioned sonames ... Second LIBCLANG_PATH failure mode: my 'libclang.so.*' with -type f pattern returned nothing because Debian Bookworm's runtime library is 'libclang-14.so.1' (versioned, with no plain libclang.so.* symlink), and the .so symlink is itself a symlink not a regular file (-type f excludes it). bindgen accepts any of: libclang.so, libclang-*.so, libclang.so.*, libclang-*.so.* — so the broader 'libclang*.so*' (no -type filter) catches every variant. Also broadened search root from /usr/lib to /usr to cover both /usr/lib/x86_64-linux-gnu/ (runtime lib) and /usr/lib/llvm-*/lib/ (dev symlink). Log line now includes the actual matched path so future debugging is one glance.	2026-06-28 17:20:02 +08:00
dailz	4e65f4175b	ci(gitea): dynamically resolve LIBCLANG_PATH for act_runner container ... First real CI run on the Gitea Actions runner hit the predicted LIBCLANG_PATH issue but for an unexpected reason: workflow-level 'env:' does not reliably propagate into act_runner's Docker executor (bindgen received empty LIBCLANG_PATH despite /usr/lib/llvm-*/lib being correct on the runner). Two changes: 1. Drop the hardcoded workflow-level 'env: LIBCLANG_PATH' and add a dedicated 'Resolve LIBCLANG_PATH' step that does: find /usr/lib -name 'libclang.so.*' | head -1 | xargs dirname and writes the result to $GITHUB_ENV. Dynamic discovery also future-proofs against Debian/Ubuntu version drift (llvm-14 today, llvm-18 tomorrow). The $GITHUB_ENV mechanism is reliably visible across step boundaries inside the act_runner Docker container, whereas workflow-level env: is not. 2. apt install: drop '--no-install-recommends' on libclang-dev (Debian Bookworm's metapackage uses Recommends to pull in versioned toolchain bits bindgen needs). Also install 'clang' (not just llvm-14) to get version-agnostic libclang shared lib. Comments inline in ci.yml document both decisions to prevent future regression. The 'Resolve LIBCLANG_PATH' step fails fast with a clear message if libclang isn't installed, instead of letting the clippy/build steps fail cryptically later.	2026-06-28 16:58:04 +08:00
dailz	ed39d3d873	ci: add build/test/clippy gate + cargo audit; pin rust-version ... Oracle P2 plan step 1+2+missed-fields. Locks in the audit cleanup so future PRs can't regress the 0-errors / deny-unsafe / 79-tests baseline. - .github/workflows/ci.yml: two jobs on ubuntu-latest (Linux only — project is Wayland/VAAPI-specific, no macOS/Windows story). * build-test: installs ffmpeg + libavcodec/libavformat/libavutil/ libswscale/libva dev + libwayland + libdrm + libpipewire-0.3-dev + libclang-dev/llvm-14 (LIBCLANG_PATH pinned); caches cargo + target; runs clippy -> build --release -> test --release. Release build before tests is mandatory because tests/integration_test.rs shells out to target/release/wl-webrtc. * audit: installs cargo-audit and runs 'cargo audit --deny warnings' as a separate job so a RUSTSEC advisory fails the build independently of compile state. No -D warnings on clippy yet — undocumented_unsafe_blocks is already deny via Cargo.toml; remaining warnings are advisory and can be tightened later. - Cargo.toml: pin rust-version = '1.70' to match README's claim. Without this, cargo builds silently on older toolchains and surfaces errors as cryptic parse failures instead of a clean version-mismatch message. Oracle flagged this as a missing field during P2 review. License field intentionally omitted — repo has no LICENSE file and no publication plan yet. Add when publication becomes a goal. Verified locally: YAML parses, cargo build --release Finished in 9.82s, cargo test --release 79 passed, cargo clippy 0 errors.	2026-06-28 14:31:42 +08:00