Address browser testing reliability in CI environments:
## CI/CD Improvements
- **ChromeDriver**: Use latest stable version instead of pinned version for better compatibility
- **Timeouts**: Add 10-minute timeout for integration tests to prevent CI hangs
- **Environment Variables**: Configure WALLABY_MAX_WAIT_TIME for CI-specific timeouts
## Wallaby Configuration Enhancements
- **Chrome Args**: Add CI-stable Chrome options (--no-sandbox, --disable-dev-shm-usage)
- **Window Size**: Set consistent 1280x720 window size for reproducible tests
- **Dynamic Timeouts**: Environment-configurable max wait time with sensible defaults
- **Pool Size**: Limit to single browser instance to prevent resource conflicts
## Benefits
- ✅ More reliable test execution in CI environments
- ✅ Better error handling and timeout management
- ✅ Consistent browser behavior across environments
- ✅ Reduced flakiness from resource constraints
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit implements browser-based integration testing for the Phoenix LiveView
application using Wallaby and ChromeDriver to test the complete user experience
including JavaScript interactions.
## Changes Made
### Testing Infrastructure
- Add Wallaby dependency for browser automation testing
- Configure Chrome driver with headless mode for CI/CD
- Set up Phoenix server integration for test environment
- Enable screenshot capture on test failures
### Integration Tests
- `test/integration/simple_integration_test.exs` - Basic homepage functionality
- `test/integration/map_integration_test.exs` - Map interface and routing tests
- Tests validate page loading, content rendering, and navigation
### CI/CD Integration
- Update GitHub Actions workflow to install ChromeDriver
- Add separate integration test step in CI pipeline
- Configure headless Chrome for automated testing
### Configuration Updates
- Enable Phoenix server in test environment for Wallaby
- Configure Wallaby with proper base URL and screenshot settings
- Initialize Wallaby application in test helper
## Features Tested
- ✅ Homepage loads with APRS content
- ✅ Main page structure renders correctly
- ✅ Route navigation functions properly
- ✅ Basic Phoenix LiveView functionality
## Next Steps
This provides a solid foundation for expanding to test:
- Interactive map controls and JavaScript functionality
- Real-time packet updates via LiveView PubSub
- User authentication flows and form submissions
- Mobile responsive behavior
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Previously, the deployment timestamp was set to DateTime.utc_now() when
the application started, which meant it would always show as recent in
k8s environments where pods are recreated on each deployment.
This commit:
- Updates Release.init() to check for DEPLOYED_AT environment variable
- Falls back to current time if env var is not set (backwards compatible)
- Adds proper ISO8601 timestamp parsing with error handling
- Updates GitHub Actions deploy workflow to set DEPLOYED_AT during deployment
- Creates k8s patch file for future manual deployments
The deployment timestamp will now persist across pod restarts in k8s,
showing the actual deployment time rather than pod startup time.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Re-add Docker Buildx setup (required for cache)
- Use 'type=inline' for cache-to (embeds cache in image)
- Cache from the latest image instead of separate buildcache tag
This fixes the 'Cache export is not supported' error.
Co-Authored-By: Claude <noreply@anthropic.com>
- Remove BuildKit advanced features that were slowing builds
- Remove multi-platform builds (only build for amd64)
- Remove security scanning stage
- Remove complex caching mounts
- Simplify to basic 2-stage build
- Use registry cache instead of GitHub Actions cache
This should reduce build time from 10+ minutes to 2-3 minutes.
Co-Authored-By: Claude <noreply@anthropic.com>
- Cancels any in-progress deployment when a new commit is pushed
- Prevents multiple deployments from running simultaneously
- Uses concurrency group based on branch ref
- Saves CI/CD resources and prevents conflicting deployments
Co-Authored-By: Claude <noreply@anthropic.com>
The CI/CD pipeline now initiates the deployment but doesn't wait for it to complete, allowing the workflow to finish quickly even if pods take time to start.
Co-Authored-By: Claude <noreply@anthropic.com>
Update kubectl commands in deploy workflow to target statefulset
instead of deployment, matching the recent migration to StatefulSet.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Updates Claude workflow to pull git submodules recursively, which resolves
compilation errors for Aprs.Types.MicE struct that is defined in the
vendor/aprs submodule.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Force k3s to pull the latest image by adding rollout restart
after setting the image. This ensures the cluster always runs
the most recent build even when using the :latest tag.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Changed kubectl deployment command to use :latest tag
- Updated k8s deployment manifests to use ghcr.io/aprsme/aprs.me:latest
- This ensures k3s always pulls the most recent image from GitHub Container Registry
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
The deployment was using raw SHA but the Docker metadata action creates
tags with 'main-' prefix for the main branch. Updated kubectl command
to use the correct tag format: main-${github.sha}
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Replace deprecated gleam-lang/setup-gleam@v1 with erlef/setup-beam which supports
Gleam alongside Elixir and Erlang. This consolidates setup steps and uses the
actively maintained action.
The previous gleam-lang/setup-gleam action is deprecated and v1 tag doesn't exist,
causing CI failures. erlef/setup-beam is the recommended replacement.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Rename Gleam module from encoding_simple to encoding
- Move Gleam files from src/aprs/ to src/aprsme/ to match project namespace
- Create custom Mix task for Gleam compilation (lib/mix/tasks/gleam_compile.ex)
- Update EncodingUtils to wrap Gleam implementation instead of pure Elixir
- Add Gleam dependencies to mix.exs and configure build paths
- Update Mix aliases to include Gleam compilation in test and compile tasks
- Add Gleam support to GitHub Actions CI workflow with caching
- Add GLEAM_INTEGRATION.md documentation
- All 357 tests passing with Gleam integration
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit introduces a complete setup for deploying the Phoenix application
to a K3s Kubernetes cluster, along with a GitHub Actions workflow for
automated builds and deployments.
Key changes include:
- **Kubernetes Manifests (`k8s/`)**:
- Namespace (`aprs-app`) for isolating application resources.
- PostgreSQL setup: PersistentVolumeClaim, Deployment, and Service.
- Application setup: Deployment (with init container for migrations) and
Service (NodePort).
- An example secrets file (`k8s/secrets.yaml.example`) for configuration.
- `.gitignore` updated to exclude `k8s/secrets.yaml`.
- **GitHub Actions Workflow (`.github/workflows/deploy-k3s.yaml`)**:
- Builds the Docker image on pushes to the main branch.
- Pushes the image to GitHub Container Registry (GHCR).
- Deploys the application to K3s by applying the manifests.
- Dynamically updates the application deployment with the correct image tag.
- Requires `KUBE_CONFIG_DATA` GitHub secret for K3s authentication.
- **Application Configuration (`config/runtime.exs`)**:
- Commented out `libcluster` configuration specific to Fly.io to prevent
issues in a standard K3s environment.
- **Documentation (`README.md`)**:
- Added a new "Kubernetes (K3s) Deployment" section detailing:
- Prerequisites and initial setup (GitHub & K8s secrets).
- Workflow overview.
- Application configuration notes (health checks, migrations).
- Instructions for accessing the application.
This setup provides a robust foundation for CI/CD and running the
application in a self-hosted K3s environment.
