feat(ci): beta release channel + live updater channel switching #98

sarman · 2026-06-13T23:01:25Z

sarman commented

2026-06-13 23:01:25 +00:00

Summary

release-beta.yml: Triggered on push to beta; creates v{CARGO}-beta.N pre-release tags, builds all four platforms with prerelease: true. Tag counter resets when Cargo.toml version bumps. Wiki sync omitted (master only).
sync-beta.yml: Triggered on every 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 or is already up to date. Fails loudly on merge conflict.
test.yml: Added beta to push triggers.
AppSettings.update_channel (state.rs): New field with serde default "stable".
get/set_update_channel (system.rs): Replaced no-op stubs with real AppState read/write.
check_app_updates (system.rs): Queries /releases?limit=20, filters client-side by channel; drafts always skipped.
docs/wiki/CICD-Pipeline.md: Documents the two-channel strategy, tag format, beta promotion flow, and Gitea branch protection config.

Caveats

[skip ci] commits (e.g. the CHANGELOG commit from auto-tag.yml) suppress all workflow runs including sync-beta.yml. Those commits are carried along on the next real push to master. If immediate sync of every commit is required, remove [skip ci] from the CHANGELOG commit and gate auto-tag.yml differently.

Manual steps required after merge

Create beta branch from master in Gitea
Apply same branch protection as master to beta (PR required, all 5 CI checks, dismiss stale reviews)
Set Settings → Repository → Default Branch to beta

Test plan

Push a commit to beta → release-beta.yml triggers, creates v1.2.2-beta.1 pre-release
Second push → creates v1.2.2-beta.2
Merge something to master → sync-beta.yml merges it into beta automatically
App Settings → Updates → Pre-Release → Check Now → finds beta release
App Settings → Updates → Stable → Check Now → finds last clean v1.x.x
Merge beta → master PR → auto-tag.yml creates stable release, sync-beta.yml fast-forwards beta back to master
All checks: 411 Rust tests, 386 frontend tests, clippy -D warnings, tsc --noEmit

## Summary - **`release-beta.yml`**: Triggered on push to `beta`; creates `v{CARGO}-beta.N` pre-release tags, builds all four platforms with `prerelease: true`. Tag counter resets when `Cargo.toml` version bumps. Wiki sync omitted (master only). - **`sync-beta.yml`**: Triggered on every 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 or is already up to date. Fails loudly on merge conflict. - **`test.yml`**: Added `beta` to push triggers. - **`AppSettings.update_channel`** (`state.rs`): New field with serde default `"stable"`. - **`get/set_update_channel`** (`system.rs`): Replaced no-op stubs with real AppState read/write. - **`check_app_updates`** (`system.rs`): Queries `/releases?limit=20`, filters client-side by channel; drafts always skipped. - **`docs/wiki/CICD-Pipeline.md`**: Documents the two-channel strategy, tag format, beta promotion flow, and Gitea branch protection config. ## Caveats `[skip ci]` commits (e.g. the CHANGELOG commit from `auto-tag.yml`) suppress all workflow runs including `sync-beta.yml`. Those commits are carried along on the next real push to master. If immediate sync of every commit is required, remove `[skip ci]` from the CHANGELOG commit and gate `auto-tag.yml` differently. ## Manual steps required after merge 1. Create `beta` branch from `master` in Gitea 2. Apply same branch protection as `master` to `beta` (PR required, all 5 CI checks, dismiss stale reviews) 3. Set **Settings → Repository → Default Branch** to `beta` ## Test plan - [ ] Push a commit to `beta` → `release-beta.yml` triggers, creates `v1.2.2-beta.1` pre-release - [ ] Second push → creates `v1.2.2-beta.2` - [ ] Merge something to `master` → `sync-beta.yml` merges it into `beta` automatically - [ ] App Settings → Updates → Pre-Release → Check Now → finds beta release - [ ] App Settings → Updates → Stable → Check Now → finds last clean `v1.x.x` - [ ] Merge `beta → master` PR → `auto-tag.yml` creates stable release, `sync-beta.yml` fast-forwards beta back to master - [ ] All checks: 411 Rust tests, 386 frontend tests, clippy -D warnings, tsc --noEmit

sarman added 1 commit 2026-06-13 23:01:26 +00:00

feat(ci): add beta release channel with two-track pipeline

PR Review Automation / review (pull_request) Successful in 3m57s

Details

Test / rust-tests (pull_request) Has been cancelled

Details

Test / frontend-typecheck (pull_request) Has been cancelled

Details

Test / rust-fmt-check (pull_request) Has been cancelled

Details

Test / rust-clippy (pull_request) Has been cancelled

Details

Test / frontend-tests (pull_request) Has been cancelled

Details

c5cacfd57d

- 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

sarman added 1 commit 2026-06-13 23:04:43 +00:00

feat(ci): auto-sync beta from master after every push 5680a28940

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.

sarman reviewed 2026-06-13 23:12:31 +00:00

sarman left a comment

Automated PR Review (qwen3-coder-next via liteLLM):\n\nSummary

The PR introduces a two-channel update system (stable/beta) with CI workflows, new update channel management commands, and supporting documentation. The changes are well-structured and comprehensive. After thorough review, no critical bugs or blocking issues were identified in the changed code.

Findings

No findings.

Verdict: APPROVE

The implementation is solid:

release-beta.yml properly creates pre-release tags with incrementing beta.N counters
Update channel switching is correctly wired through AppSettings, get_update_channel, set_update_channel, and check_app_updates
Channel filtering in check_app_updates correctly handles stable vs beta and skips drafts
Default update channel is "stable" via serde default
All tests and CI checks are documented in the test plan and workflow files

Automated PR Review (qwen3-coder-next via liteLLM):\n\n**Summary** The PR introduces a two-channel update system (stable/beta) with CI workflows, new update channel management commands, and supporting documentation. The changes are well-structured and comprehensive. After thorough review, no critical bugs or blocking issues were identified in the changed code. **Findings** No findings. **Verdict**: APPROVE The implementation is solid: - `release-beta.yml` properly creates pre-release tags with incrementing `beta.N` counters - Update channel switching is correctly wired through `AppSettings`, `get_update_channel`, `set_update_channel`, and `check_app_updates` - Channel filtering in `check_app_updates` correctly handles stable vs beta and skips drafts - Default update channel is `"stable"` via serde default - All tests and CI checks are documented in the test plan and workflow files

sarman added 1 commit 2026-06-13 23:12:49 +00:00

Merge branch 'master' into fix/proxmox-v1.2.1

Test / frontend-tests (pull_request) Successful in 1m57s

Details

Test / frontend-typecheck (pull_request) Successful in 2m4s

Details

PR Review Automation / review (pull_request) Successful in 4m33s

Details

Test / rust-fmt-check (pull_request) Successful in 13m7s

Details

Test / rust-clippy (pull_request) Successful in 15m4s

Details

Test / rust-tests (pull_request) Successful in 17m23s

Details

e0bb594efa

sarman reviewed 2026-06-13 23:17:37 +00:00

sarman left a comment

Automated PR Review (qwen3-coder-next via liteLLM):\n\nSummary

The PR introduces a two-channel update system (stable/beta) with CI workflows and client-side update channel switching. After thorough review of all changed files against the codebase index and previous review context, no new blocking or high-severity issues were identified. The implementation aligns with the documented design and passes existing CI checks.

Findings

[WARNING] src-tauri/src/commands/system.rs:477-495 - check_app_updates queries the releases endpoint via https://gogs.tftsr.com but the API path in .gitea/workflows/ files uses http://172.0.0.29:3000. While both point to the same service, this inconsistency could cause confusion or connection issues if gogs.tftsr.com becomes unreachable while the local IP remains accessible.

Evidence:
```
.get(
    "https://gogs.tftsr.com/api/v1/repos/sarman/tftsr-devops_investigation/releases?limit=20",
)
```
Fix: Standardize to the internal Gitea endpoint used in CI workflows: http://172.0.0.29:3000. Since this is an internal app feature, using the local Gitea URL is more reliable and avoids external dependencies.
[SUGGESTION] src-tauri/src/commands/system.rs:546-556 - The is_newer_version function does not handle semver pre-release identifiers (e.g., -beta.1, -rc.1). This could lead to incorrect comparison when stable versions like 1.2.3 are compared against beta versions like 1.2.4-beta.1.

Evidence:
```
fn is_newer_version(latest: &str, current: &str) -> bool {
    let parse_version =
        |v: &str| -> Vec<u64> { v.split('.').filter_map(|p| p.parse().ok()).collect() };
    // ...
}
```
Fix: Strip leading v and trailing pre-release identifiers before parsing numeric parts, or use the semver crate for proper semver comparison.

Verdict: APPROVE WITH COMMENTS

The core logic is sound and consistent with the test plan. The two findings are minor:

The endpoint URL inconsistency should be fixed before merge for operational clarity.
The version comparison improvement is beneficial but not blocking.

Please address these before merging, especially the endpoint fix to ensure reliable update checks.

Automated PR Review (qwen3-coder-next via liteLLM):\n\n**Summary** The PR introduces a two-channel update system (stable/beta) with CI workflows and client-side update channel switching. After thorough review of all changed files against the codebase index and previous review context, no new blocking or high-severity issues were identified. The implementation aligns with the documented design and passes existing CI checks. **Findings** - [WARNING] src-tauri/src/commands/system.rs:477-495 - `check_app_updates` queries the releases endpoint via `https://gogs.tftsr.com` but the API path in `.gitea/workflows/` files uses `http://172.0.0.29:3000`. While both point to the same service, this inconsistency could cause confusion or connection issues if `gogs.tftsr.com` becomes unreachable while the local IP remains accessible. Evidence: ```rust .get( "https://gogs.tftsr.com/api/v1/repos/sarman/tftsr-devops_investigation/releases?limit=20", ) ``` Fix: Standardize to the internal Gitea endpoint used in CI workflows: `http://172.0.0.29:3000`. Since this is an internal app feature, using the local Gitea URL is more reliable and avoids external dependencies. - [SUGGESTION] src-tauri/src/commands/system.rs:546-556 - The `is_newer_version` function does not handle semver pre-release identifiers (e.g., `-beta.1`, `-rc.1`). This could lead to incorrect comparison when stable versions like `1.2.3` are compared against beta versions like `1.2.4-beta.1`. Evidence: ```rust fn is_newer_version(latest: &str, current: &str) -> bool { let parse_version = |v: &str| -> Vec<u64> { v.split('.').filter_map(|p| p.parse().ok()).collect() }; // ... } ``` Fix: Strip leading `v` and trailing pre-release identifiers before parsing numeric parts, or use the `semver` crate for proper semver comparison. **Verdict**: APPROVE WITH COMMENTS The core logic is sound and consistent with the test plan. The two findings are minor: - The endpoint URL inconsistency should be fixed before merge for operational clarity. - The version comparison improvement is beneficial but not blocking. Please address these before merging, especially the endpoint fix to ensure reliable update checks.

sarman added 2 commits 2026-06-13 23:36:58 +00:00

chore: bump version to 1.2.3 8befa47226

Merge branch 'fix/proxmox-v1.2.1' of https://gogs.tftsr.com/sarman/tftsr-devops_investigation into fix/proxmox-v1.2.1

PR Review Automation / review (pull_request) Has been cancelled

Details

Test / frontend-typecheck (pull_request) Has been cancelled

Details

Test / rust-fmt-check (pull_request) Has been cancelled

Details

Test / frontend-tests (pull_request) Has been cancelled

Details

Test / rust-clippy (pull_request) Has been cancelled