feat: Add update mode selection and branch tracking (fixes #114) #118
Conversation
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
This commit addresses issue #114 by implementing a comprehensive update system with flexible update detection modes and branch tracking capabilities. ## Key Features ### Update Modes - **Stable Mode**: Tracks VERSION file changes for semantic versioning - Only reports updates when version number increases - Ideal for production environments wanting controlled releases - **Development Mode**: Tracks all commits on selected branch - Reports updates for any new commits - Perfect for development/testing environments ### Branch Tracking (Development Mode) - List all available remote branches - Select and track specific branches for updates - Automatic detection of current branch - Visual indicators for current and tracked branches ## Changes ### Server (server/system/update_manager.py) - Added UpdateMode enum (STABLE, DEVELOPMENT) - Added configure_update_mode() method - Added get_available_branches() method - Added set_tracked_branch() method - Enhanced check_for_updates() to support both modes - Added tracked_branch attribute to status ### API (server/api/system.py) - Added /system/update/configure-mode endpoint - Added /system/update/branches endpoint - Added /system/update/set-tracked-branch endpoint - Added request models for new endpoints ### Client API (client/api/client.py) - Added configure_update_mode() method - Added get_available_branches() method - Added set_tracked_branch() method ### GUI (client/ui/system_panel.py) - Added mode selector dropdown (Stable/Development) - Added branch selector with refresh button - Auto-shows/hides branch selector based on mode - Added handlers for mode and branch changes - Visual feedback and logging for all operations ## Benefits - Fixes "Check for updates not functional" issue - Provides flexibility for different deployment scenarios - Enables testing of feature branches before merging - Better developer experience with branch visibility 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Implements configuration persistence and automatic initialization for the update system, allowing settings to survive server restarts. ## Key Features ### Configuration Persistence - All update settings are now automatically saved to config/update_config.json - Settings persist across server restarts - Includes: update mode, tracked branch, auto-rebuild, scheduled checks ### Auto-Start on Server Startup - Scheduled update checks auto-start if previously enabled - Loads saved configuration during UpdateManager initialization - Integrates with server lifespan management ### Graceful Shutdown - Properly stops scheduled checks on server shutdown - Cleans up background tasks - Saves configuration before exit ## Changes ### Server (server/system/update_manager.py) - Added config_file path (config/update_config.json) - Added _load_config() method to restore saved settings - Added _save_config() method to persist current settings - Added initialize() method for auto-start logic - Modified all configuration methods to call _save_config() - Configuration includes: - update_mode (stable/development) - tracked_branch - auto_rebuild settings - scheduled check settings (enabled, interval, remote, branch) ### Server Startup (server/main.py) - Added update_manager.initialize() to lifespan startup - Added scheduled checks cleanup to lifespan shutdown - Logs initialization and shutdown status ## Benefits - Settings persist across restarts (no need to reconfigure) - Scheduled checks resume automatically if enabled - Better production deployment experience - Configuration is human-readable JSON ## Testing Created test_config_persistence.py to verify: - Configuration saves correctly - Configuration loads on new instance - Auto-start works when scheduled checks enabled - Configuration changes persist ✅ All tests pass successfully 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Adds robust directory tree search to find project root instead of relying on fixed relative paths. This fixes "not a git repository" error when switching to development mode. ## Changes - Added _find_project_root() method that searches up directory tree - Looks for common markers: .git, setup.py, pyproject.toml, VERSION, README.md - Falls back to old method if no markers found - Added debug logging for root directory and git detection ## Fixes - Resolves "failed to get branches: not a git repository" error - Works regardless of how/where server is started - More reliable in different deployment scenarios 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Implemented a comprehensive client-driven update system where the client (with git repository) manages updates to both the server (running in Docker) and itself. This resolves the architectural issue where the server was trying to use git commands inside a Docker container. Key Features: 1. Client-side git operations (client/utils/git_operations.py): - get_git_tags() - List tags for stable mode - get_git_branches() - List branches for development mode - checkout_git_ref() - Checkout tag or branch - get_git_root() - Get repository root - get_current_git_branch() - Get current branch 2. Docker rebuild management (client/utils/docker_operations.py): - rebuild_docker_local() - Local Docker rebuild - rebuild_docker_ssh() - Remote Docker rebuild via SSH - is_docker_available_locally() - Check Docker availability - generate_rebuild_instructions() - Manual instructions - Hybrid approach: automatic with manual fallback 3. Client self-update capability (client/utils/self_update.py): - mark_for_update() - Flag client for update on restart - check_update_flag() - Check for pending update - perform_client_update() - Execute the update - Uses .client_update flag file for persistence 4. Enhanced System Panel GUI (client/ui/system_panel.py): - Version selector for stable mode (git tags dropdown) - Branch selector for development mode - Docker rebuild section with SSH support - Server version check and comparison - _update_server() - Client-driven server updates - _update_client() - Client self-update with restart - Hybrid rebuild: tries automatic, shows manual on failure 5. Launcher enhancements (client/main.py): - Checks for pending client update on startup - Applies update before launching GUI if flagged - Easter egg mode (--easter-egg flag) - Secret branch selector in easter egg mode - Allows developers to switch branches on launch Architecture: - Client has git repository and performs all git operations locally - Server runs in Docker and is passive (only reports version via API) - Mode selection (stable/development) applies to both client and server - Supports both local and remote Docker (via SSH) - Client can update itself through flag file mechanism - Easter egg mode for developer branch switching Usage: - Normal: python client/main.py - Easter egg: python client/main.py --easter-egg Issue: #114 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Changed _refresh_branches() to use local git operations instead of server API calls. This fixes the 'Not a git repository' error when switching to development mode in the System Panel. Also simplified _on_branch_changed() since the client now manages all updates locally without needing to notify the server. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
When debug mode is enabled in the launcher (by clicking the header 7 times), the client will now launch with both --debug and --easter-egg flags. This shows the secret branch selector dialog before the client GUI starts. This provides a seamless developer experience: 1. Click launcher header 7 times to enable debug mode 2. Click 'Start Client' button 3. Branch selector dialog appears automatically 4. Select branch/tag and click OK 5. Client launches with that branch Also fixed branch listing to use client-side git operations instead of server API calls. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Set minimum width of 400px for both version selector and branch selector dropdowns to allow longer branch/version names to be fully visible. This improves usability when dealing with descriptive branch names like 'feature/update-system-modes-branch-tracking-issue-114'. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Increased minimum width from 400px to 500px for both version and branch selector dropdowns to provide even more space for long branch names. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
X9X0
deleted the
feature/update-system-modes-branch-tracking-issue-114
branch
X9X0
added a commit
that referenced
this pull request
Dec 7, 2025
…ecture ## Summary Unified version management across all components (server, client, launcher, Docker) using a single VERSION file as the source of truth. Updated to v1.2.0 to accurately reflect work completed since v1.0.0 (30+ PRs merged). ## Version System Changes ### Unified to v1.2.0 - Analyzed git history from v1.0.0 through current main - Determined v1.2.0 accurately represents features and fixes delivered - All components now read from single VERSION file ### Components Updated - VERSION file: 0.28.0 → 1.2.0 - README badge: 1.0.1 → 1.2.0 - Server: Now reads VERSION (already implemented) - Client: Added dynamic VERSION reading at startup - Launcher: Added __version__ variable from VERSION - Docker images: Labels updated to 1.2.0 - Copyright: Updated to © 2025 (project start year) ## CHANGELOG Updates Added comprehensive release notes for missing versions: ### v1.2.0 (2025-12-06) - Server update system with stable/development modes (#114, #118, #119) - Smart branch filtering and UI consolidation (#120) - Enhanced dropdown visibility - Multiple bug fixes (#105, #106, #108, #121) ### v1.0.1 (2025-11-28) - Equipment control panel (#104) - GUI system launcher with diagnostics (#70-74) - Raspberry Pi image builder (#75-76) - Waveform analysis tools (#79) - Automated test sequence builder (#80) - Remote firmware update (#81) - Equipment diagnostics system (#84-87) - WebSocket integration completion (#77) ## Automation & Documentation ### Created scripts/bump_version.py Automated version bumping tool with: - Support for major/minor/patch increments - Automatic VERSION file updates - CHANGELOG.md section generation - Git commit and tag creation - Dry-run mode for testing Usage: python scripts/bump_version.py patch # 1.2.0 → 1.2.1 python scripts/bump_version.py minor # 1.2.0 → 1.3.0 python scripts/bump_version.py major # 1.2.0 → 2.0.0 ### Created docs/VERSIONING.md Complete versioning system documentation covering: - Single-source architecture - Semantic versioning guidelines - Automated bumping procedures - Manual update processes - Troubleshooting guide - Best practices ## Files Modified Core Version Files: - VERSION (0.28.0 → 1.2.0) - CHANGELOG.md (added v1.0.1 and v1.2.0 entries) - README.md (badge updated to 1.2.0) Component Updates: - client/main.py (dynamic VERSION reading) - lablink.py (added __version__ from VERSION) - docker/Dockerfile.server (label 1.2.0) - docker/Dockerfile.web (label 1.2.0) Copyright Updates (© 2025): - docs/USER_GUIDE.md - client/ui/main_window.py New Files: + scripts/bump_version.py (version management tool) + docs/VERSIONING.md (complete documentation) ## Benefits ✅ Single source of truth for version (VERSION file) ✅ Consistent versioning across all components ✅ Accurate version history in CHANGELOG ✅ Automated version bumping workflow ✅ Complete documentation for future updates ✅ Git-tagged releases (v1.2.0) ## Testing Verified: - VERSION file: 1.2.0 ✓ - Server reads VERSION correctly ✓ - Client would read VERSION at startup ✓ - Launcher reads VERSION correctly ✓ - bump_version.py dry-run works ✓ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
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.
Client-Driven Update System Implementation
Implements a comprehensive client-driven update system where the client (with git repository) manages updates to both the server (running in Docker) and itself. This resolves the
architectural issue where the server was attempting to use git commands inside a Docker container without git installed.
Closes #114
🎯 Key Features
1. Client-Side Git Operations
client/utils/git_operations.py2. Docker Rebuild Management
client/utils/docker_operations.pydocker compose down/build/up)--no-cacheflag support3. Client Self-Update
client/utils/self_update.py.client_update) for update persistence4. Enhanced System Panel GUI
Version Management (Stable Mode):
Branch Management (Development Mode):
Docker Rebuild Controls:
Client Self-Update:
5. Easter Egg Mode (Developer Feature)
--easter-eggcommand-line flag6. Launcher Integration
--easter-eggflag automatically🐛 Bug Fixes
_refresh_branches()now uses client-side git operations🏗️ Architecture Changes
Before:
Server (Docker) → Tries to run git commands → ❌ Fails (no git in container)
After:
Client (with git) → Runs git operations locally → ✅ Success
Client → Triggers Docker rebuild → Server updated
Client → Can update itself → Restart and apply
📋 Technical Details
Update Modes:
Supported Environments:
Self-Update Flow:
.client_updateEaster Egg Activation:
python client/main.py --easter-egg🧪 Testing
Manually tested:
📸 UI Improvements
🔄 Backward Compatibility
📚 Usage Examples
Check for server updates:
Update server (Docker):
Update client:
Easter egg mode: