Master added `unset SODIUM_USE_PKG_CONFIG` to the linux-amd64 and
linux-arm64 build steps in auto-tag.yml (PR #111). Beta's copy of
auto-tag.yml was already ahead of master via the previous sync but
lacked those two unset lines, causing a line-level conflict.
Resolution: take master's version in both conflict regions, adding the
unset to both linux build steps. All three platforms (amd64, Windows,
arm64) now have consistent SODIUM_LIB_DIR + unset configuration.
The libsodium-sys-stable build.rs panics when both SODIUM_LIB_DIR and
SODIUM_USE_PKG_CONFIG are set simultaneously. The runner environment at
172.0.0.29 has SODIUM_USE_PKG_CONFIG set (not traceable to any workflow
file or Docker image ENV layer), which conflicts with any step that sets
SODIUM_LIB_DIR.
For all three platform builds (linux-amd64, windows-amd64, linux-arm64):
- Add `unset SODIUM_USE_PKG_CONFIG` to the shell before cargo runs
- Switch Linux builds from inline apt-get to SODIUM_LIB_DIR (Docker
images already include libsodium-dev, removing the redundant install)
- Extend arm64 PKG_CONFIG_PATH to include /usr/aarch64-linux-gnu/lib/pkgconfig
(matching the beta workflow for consistency)
The unset is a no-op when the variable is absent; it cleanly clears any
ambient value injected by the runner infrastructure.
Tested locally with Ubuntu 22.04 + libsodium-sys-stable 1.24.0:
- No env vars → install_from_source() needs 'make', fails in slim containers
- SODIUM_LIB_DIR alone → works when libsodium is installed in the image
- SODIUM_LIB_DIR + SODIUM_USE_PKG_CONFIG → immediate panic (incompatible by design)
Fixes three broken build targets introduced by the merge conflict resolution:
- linux-amd64: was missing all sodium config, add SODIUM_LIB_DIR
- windows: had SODIUM_LIB_DIR + SODIUM_USE_PKG_CONFIG (incompatible), remove the latter
- linux-arm64: was missing sodium config, add SODIUM_LIB_DIR
tauri-plugin-stronghold pulls in libsodium-sys-stable which panics at
build time if libsodium is not found via pkg-config — it does not compile
from source. All builder images and the test job inline apt installs were
missing libsodium-dev, breaking every Rust compilation step.
- Add libsodium-dev to Dockerfile.linux-amd64
- Add libsodium-dev (host) + libsodium-dev:arm64 (cross target) to
Dockerfile.linux-arm64
- Add libsodium-dev to all three Rust jobs in test.yml
- Add inline apt-get install to linux-amd64 and linux-arm64 Build steps
in auto-tag.yml and release-beta.yml (bridges the timing race between
build-images and auto-tag triggering on the same push)
- Add SODIUM_LIB_DIR + SODIUM_STATIC to Windows Build env (Dockerfile
already pre-builds libsodium; this tells the crate where to find it)
Moved SODIUM_LIB_DIR from per-step env blocks to job-level env for all
three Rust test jobs (rust-fmt-check, rust-clippy, rust-tests).
Benefits:
- Applies to ALL cargo commands in the job, including generate-lockfile
- More maintainable - single declaration per job
- Consistent with best practices for job-wide environment variables
Addresses automated review feedback.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Directly specify libsodium library paths via SODIUM_LIB_DIR environment
variable instead of relying on pkg-config detection. This is the highest
priority method in libsodium-sys-stable's build.rs and bypasses all
pkg-config/vcpkg logic.
Platform-specific paths:
- Linux x86_64: /usr/lib/x86_64-linux-gnu
- Linux aarch64: /usr/lib/aarch64-linux-gnu
- Windows MinGW: /usr/x86_64-w64-mingw32/lib
Changes:
- test.yml: Add SODIUM_LIB_DIR to all cargo commands
- auto-tag.yml: Add SODIUM_LIB_DIR to all build jobs
This resolves "libsodium not found via pkg-config or vcpkg" by telling
the build script exactly where libsodium is installed.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The test.yml workflow's rust-fmt-check, rust-clippy, and rust-tests
jobs were missing libsodium-dev package installation. With the new
use-pkg-config feature enabled, pkg-config must be able to find
libsodium system libraries.
This resolves "libsodium not found via pkg-config" failures in the
test pipeline.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Explicitly adds libsodium-sys-stable dependency with use-pkg-config
feature to ensure builds use system libsodium via pkg-config instead
of attempting vendored builds.
Changes:
- Add direct dependency on libsodium-sys-stable with use-pkg-config feature
- Update Windows build to use pkg-config with cross-compilation support
- Remove manual SODIUM_* env vars that bypass pkg-config
This resolves "libsodium not found via pkg-config or vcpkg" build
failures on Linux and Windows CI targets.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
## Problem
Previous approach with SODIUM_USE_PKG_CONFIG=1 still failed:
"libsodium not found via pkg-config or vcpkg"
pkg-config couldn't locate libsodium.pc in CI containers despite
libsodium-dev being installed.
## Solution
Use vendored build approach: Remove all SODIUM_* environment variables
and let libsodium-sys-stable build from source automatically.
## Changes
- **release-beta.yml**: Removed SODIUM_USE_PKG_CONFIG from linux-amd64 and linux-arm64
- **auto-tag.yml**: Removed SODIUM_USE_PKG_CONFIG from linux-amd64 and linux-arm64
- **Windows**: Kept SODIUM_LIB_DIR approach (uses pre-built from Dockerfile)
## Why This Works
libsodium-sys-stable build priority:
1. SODIUM_LIB_DIR (if set) → use pre-built
2. SODIUM_USE_PKG_CONFIG (if set) → use pkg-config
3. Neither set → build from source (vendored) ✅
Vendored builds are more reliable in CI as they don't depend on
system package installation or pkg-config configuration.
## Validation
✅ Local clean build with vendored libsodium: passed
⏳ CI validation: pending
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add explicit SODIUM_USE_PKG_CONFIG control to all build targets:
- Linux amd64/arm64: Set SODIUM_USE_PKG_CONFIG=1 to force pkg-config detection
- Windows: Set SODIUM_USE_PKG_CONFIG=no to prevent conflict with SODIUM_LIB_DIR
Fixes build failures:
- Linux: "libsodium not found via pkg-config or vcpkg" despite libsodium-dev installed
- Windows: "SODIUM_LIB_DIR is incompatible with SODIUM_USE_PKG_CONFIG"
- ARM64: Same pkg-config detection issue as amd64
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add libsodium-dev to Docker build images and configure Windows cross-build
environment to fix CI build failures on all platforms (Linux amd64/arm64,
Windows amd64). Failures were caused by missing libsodium dependency
required by tauri-plugin-stronghold → iota-crypto → libsodium-sys-stable.
Changes:
- Install libsodium-dev in Linux amd64 and arm64 Docker images
- Set SODIUM_LIB_DIR and SODIUM_STATIC env vars for Windows cross-build
- Add smoke test to verify libsodium linking via stronghold dependency
- Add comprehensive test coverage (3 new tests in state module)
All 802 tests pass (416 Rust + 386 TypeScript). Zero linting warnings.
Fixes: Linux "libsodium not found via pkg-config" error
Fixes: Windows "SODIUM_LIB_DIR incompatible with SODIUM_USE_PKG_CONFIG" error
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Resolves intermittent ECONNRESET failures in CI by adding 3-retry loop
with 5s backoff to all npm ci/install steps. Also adds --prefer-offline
and --no-audit flags to reduce registry dependency.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
libsodium-sys requires memset_explicit which is not available in older
MinGW toolchains. Added a C shim that provides a fallback implementation
using volatile pointers to prevent compiler optimization.
Changes:
- Added memset_s_shim.c with fallback memset_explicit implementation
- Updated build.rs to compile shim for Windows GNU targets
- Added cc crate as build dependency
- Set CFLAGS in CI to target Windows 8+ (_WIN32_WINNT=0x0602)
- Set SODIUM_STATIC=yes to force static libsodium build
Fixes linking error: undefined reference to memset_explicit
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Adds sync-beta.yml: triggers on push to master, merges master into
beta using RELEASE_TOKEN (admin — same mechanism auto-tag.yml uses to
push CHANGELOG commits to protected master). Skips gracefully if beta
does not exist yet or is already up to date.
Note: commits with [skip ci] suppress all workflow runs; those commits
are picked up on the next real push to master.
- Add release-beta.yml: triggers on push to beta, creates
v{CARGO}-beta.N pre-release tags with prerelease: true, builds all
four platforms; tag counter resets when Cargo.toml version bumps
- Add beta to test.yml push triggers so CI runs on direct pushes to
beta (pull_request already covers PRs targeting beta)
- Implement update_channel in AppSettings (state.rs) with serde
default "stable"; wire get/set_update_channel commands to AppState
instead of returning hardcoded stubs
- Implement channel-aware check_app_updates: queries /releases?limit=20
and picks first non-draft release matching the active channel
(stable = !prerelease, beta = prerelease), skipping drafts
- Document two-channel strategy in docs/wiki/CICD-Pipeline.md
Manual steps still required in Gitea UI:
1. Create beta branch from master
2. Apply same branch protection rules as master to beta
3. Set repo default PR target branch to beta
- Detect pre-release tags (containing -rc, -alpha, -beta, -pre, -dev)
- Set prerelease: true in Gitea release API call
- Build jobs now respect pre-release status
- Follow anthropics/claude-code code-review workflow precisely
- Add PR_BODY to prompt for author intent context
- Implement 4 parallel analysis agents (2 CLAUDE.md compliance, 2 bug detectors)
- Focus on HIGH SIGNAL issues only (no nitpicks, style, speculative)
- Add validation step to verify findings against codebase
- Consider PR title/description and prior review history
- Check for pre-existing issues and avoid false positives
- Search full codebase to verify functions/variables are properly implemented
Change RENOVATE_ENDPOINT from /api/v3 to /api/v1. Gitea uses v1 for all
API routes; the /api/v3 path returns 404 which Renovate surfaces as an
authentication failure.
- Apply cargo fmt to src-tauri/src/commands/kube.rs (CI was failing)
- Update pr-review.yml to use qwen3-coder-next model via liteLLM
- Add TICKET-kube-ui-feature-parity.md gap analysis for FreeLens parity
Co-Authored-By: TFTSR Engineering <noreply@tftsr.com>
git-cliff's --tag flag sets the display label for unreleased commits;
it does not scope commits to a range. Passing a range string to --tag
caused git-cliff to emit the full cumulative history for every release.
Move the revision range from --tag to a positional argument so only
commits between PREV_TAG and CURRENT_TAG appear in each release body.
CHANGELOG.md generation is unaffected (still full history).
Add a new 'Fetch PR comment history' step that pulls both review posts
and issue comments from the Gitea API before the LLM is called.
The full comment history is injected into the prompt with an explicit
instruction to silently discard any finding already marked as invalid,
acknowledged as intentional, or confirmed fixed in a prior round.
This prevents the reviewer from repeatedly raising refuted findings
across successive push events on the same PR.
The runner environment does not have Node.js in PATH, causing
actions/checkout@v4 and renovatebot/github-action@v41.0.0 (both JS
actions) to fail at startup.
Use renovate/renovate:latest as the job container and invoke the
renovate binary directly via run:, consistent with how all other
workflows in this repo handle checkout and tooling. The Checkout step
was also unnecessary — Renovate manages its own git operations.
Fix for dbus-1 and webkit build errors:
'Package dbus-1 was not found in the pkg-config search path'
**Problem:**
rustlang/rust:nightly is a minimal image with only rustc/cargo.
Tauri requires system libraries: webkit2gtk, dbus, gtk, ssl, etc.
Without these, cargo build fails with missing pkg-config packages.
**Solution:**
Added system dependency installation step to all Rust jobs:
- libwebkit2gtk-4.1-dev (WebView)
- libdbus-1-dev (D-Bus IPC)
- libgtk-3-dev (GTK UI)
- libayatana-appindicator3-dev (System tray)
- librsvg2-dev (SVG rendering)
- libssl-dev (OpenSSL)
- pkg-config (Build tool)
**Changed Jobs:**
- rust-fmt-check: Added system deps before rustfmt
- rust-clippy: Added system deps before clippy
- rust-tests: Added system deps before tests
**Why Each Job Needs Deps:**
All jobs run 'cargo' commands which trigger dependency builds.
Even 'cargo fmt' can trigger builds if dependencies aren't cached.
System libraries must be present for Tauri crates to compile.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fix for pxfm-0.1.29 parse error:
'feature `edition2024` is required'
**Problem:**
The pxfm dependency (via moxcms → image processing) requires edition2024,
which is NOT stabilized even in Rust 1.83 stable. Error:
'edition2024 is not stabilized in this version of Cargo (1.83.0)'
**Solution:**
Switched all CI jobs from rust:1.83-bookworm to rustlang/rust:nightly.
Nightly builds include unstable features like edition2024.
**Changed:**
- rust-fmt-check: rust:1.83 → rustlang/rust:nightly
- rust-clippy: rust:1.83 → rustlang/rust:nightly
- rust-tests: rust:1.83 → rustlang/rust:nightly
**Why Nightly:**
Edition2024 is still unstable in Rust 1.83 (released Oct 2024).
Some dependencies in the image processing chain require it.
Nightly is the only option until edition2024 stabilizes.
**Note:**
Local development may use stable Rust if dependency versions are locked.
CI uses nightly to handle bleeding-edge dependencies.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fix for Cargo.toml parse error:
'feature `edition2024` is required'
**Problem:**
The toml crate v1.1.2 requires Rust edition2024 feature, which is not
stabilized in Rust 1.82. This causes cargo to fail with:
'feature `edition2024` is required... requires the nightly release'
**Solution:**
Upgraded all workflow jobs from rust:1.82-bookworm to rust:1.83-bookworm.
Rust 1.83 includes the stabilized edition2024 support.
**Changed:**
- rust-fmt-check: rust:1.82 → rust:1.83
- rust-clippy: rust:1.82 → rust:1.83
- rust-tests: rust:1.82 → rust:1.83
**Note:**
Local development uses whatever rustc is installed (currently 1.83+).
CI now matches this requirement.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fix for CI failures in rust:1.82-bookworm container:
- 'cargo-clippy' is not installed
- 'cargo-fmt' is not installed
**Solution:**
Added rustup component installation steps:
- rust-fmt-check job: Install rustfmt before format check
- rust-clippy job: Install clippy before linting
**Why Needed:**
The rust:1.82-bookworm Docker image is a minimal Rust installation.
It includes rustc and cargo, but NOT rustfmt or clippy by default.
These must be explicitly installed with 'rustup component add'.
**Verified Locally:**
- ✅ cargo fmt --check passes
- ✅ cargo clippy -- -D warnings passes (0 warnings)
- ✅ cargo test passes (308 tests)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fix for CI failure: 'exec: "node": executable file not found in /Users/sarman/.local/bin:/Users/sarman/.bun/bin:/Users/sarman/.codeium/windsurf/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/sarman/.local/bin:/Users/sarman/.opencode/bin:/Users/sarman/.cargo/bin:/opt/homebrew/opt/gnu-sed/libexec/gnubin:/Library/Frameworks/Python.framework/Versions/3.6/bin:/opt/local/bin:/opt/local/sbin:/usr/local/opt/coreutils/libexec/gnubin:/opt/metasploit-framework/bin:/Users/sarman/git/SQL:/Users/sarman/git/mass-scripts:/Users/sarman/gitpersonal:/Users/sarman/git/scripts:/Users/sarman/git/sysadmin-util:/usr/local/mysql/bin:/opt/bin/:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Applications/iTerm.app/Contents/Resources/utilities:/libexec/bin:/Users/sarman/bin/:/Users/sarman/bin/mass_scripts/:/usr/local/Cellar/mysql/5.7.21/bin:/usr/local/mariadb10/bin:/Users/sarman/bin/scripts:/Users/sarman/bin/SQL/:/Users/sarman/bin/bert_scripts/:/Users/sarman/bin/ecw/:/Users/sarman/bin/mass-scripts/:/Users/sarman/bin/nhudson:/Users/sarman/bin/personal/:/Users/sarman/bin/python_learning/:/Users/sarman/bin/svn/:/Users/sarman/sysadmin-util/:/Users/sarman/was_scripts/:/Users/sarman/.lmstudio/bin:/Users/sarman/.lmstudio/bin:/Users/sarman/.claude/plugins/cache/claude-plugins-official/swift-lsp/1.0.0/bin:/Users/sarman/.claude/plugins/cache/claude-plugins-official/rust-analyzer-lsp/1.0.0/bin:/Users/sarman/.claude/plugins/cache/knowledge-work-plugins/productivity/1.3.0/bin:/Users/sarman/.claude/plugins/cache/knowledge-work-plugins/customer-support/1.3.0/bin:/Users/sarman/.claude/plugins/cache/knowledge-work-plugins/product-management/1.2.0/bin:/Users/sarman/.claude/plugins/cache/knowledge-work-plugins/engineering/1.2.0/bin'
**Problem:**
- actions/cache@v4 requires Node.js to be installed
- rust:1.82-bookworm container doesn't include Node.js
- Installing Node.js in every job just for caching is wasteful
**Solution:**
- Removed all actions/cache@v4 steps from test.yml
- Self-hosted Gitea runners have local disk - caching less critical
- Simplifies workflow and removes Node.js dependency from Rust-only jobs
**Changes:**
- Removed cache step from rust-fmt-check job
- Removed cache step from rust-clippy job
- Removed cache step from rust-tests job
- Kept Node.js install only in rust-fmt-check (needs it for npm/version script)
**Verified Locally:**
- ✅ All format checks pass
- ✅ All clippy checks pass (0 warnings)
- ✅ All 308 Rust tests pass
- ✅ All 92 frontend tests pass
- ✅ TypeScript compiles (0 errors)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Critical fixes for Gitea compatibility:
1. **Removed .github/ directory completely**
- dependabot.yml (GitHub-only, not supported by Gitea)
- GitHub workflows (replaced by .gitea/workflows)
- CODEOWNERS, AZURE_BOARDS_INTEGRATION.md, COPILOT_SETUP.md
- These files are GitHub-specific and won't work in Gitea
2. **Fixed remaining URLs to use internal IP**
- pr-review.yml: LITELLM_URL gitea.tftsr.com:11434 → 172.0.0.29:11434
- build-images.yml: Updated comments with correct IP
- All CI runners MUST use 172.0.0.29 (internal IP)
3. **Verified branch naming**
- This repo uses 'master' (not 'main')
- All workflows correctly reference 'master'
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Replace custom CI image with public rust image to fix workflow failures.
Add Node.js installation step for rust-fmt-check job.
The custom image (gitea.tftsr.com:3000/sarman/trcaa-linux-amd64:rust1.88-node22)
needs to be built via build-images workflow first.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Quote shell:: argument to fix YAML parsing error at line 121.
The double colon was being interpreted as a YAML mapping value.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Update test workflow with shell module tests.
- Add dedicated shell module test step to .gitea/workflows/test.yml
- Tests run with --test-threads=1 for consistency
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Three issues addressed together:
1. Race condition (was PR #56): changelog job now CREATES the Gitea
release rather than assuming build jobs have already created it.
Build jobs continue to use create-or-skip + upload unchanged.
2. Detached HEAD push: 'git push origin master' fails when HEAD is
detached (no local branch named master). Changed to 'HEAD:master'.
3. git-cliff tag guard: verify tag is present locally before running
git-cliff, to fail fast with a clear message rather than silently
generating a wrong changelog.
4. git commit idiom: replaced 'git commit || echo' (swallows all
non-zero exit codes including real failures) with an explicit
'git diff --staged --quiet' guard so set -euo pipefail is not
undermined.
The changelog job checks out a specific SHA (detached HEAD) then
commits CHANGELOG.md and tries to push with 'git push origin master'.
Since there is no local branch named 'master', git rejects the push
with 'src refspec master does not match any'.
Fix: use 'git push origin HEAD:master' which explicitly maps the
current detached HEAD to the remote master branch regardless of
local branch state.
Addresses the review warning: git rev-parse confirms the tag is
present in the local repo after git fetch --tags before git-cliff
or git tag --sort= runs against it. Fails fast with a clear error
if the tag is missing rather than silently generating an incomplete
changelog.
The changelog and build-* jobs all fan out from autotag in parallel.
Build jobs create the Gitea release with 'curl ... || true', but the
changelog job was trying to GET the release before any build job had
run, reliably failing with 'Could not find release for tag vX.Y.Z'.
Fix: changelog job owns release creation. It creates the release with
the git-cliff body if it does not exist, or patches the body if a
prior run already created it. Build jobs continue using their existing
create-or-skip + upload pattern unchanged.
