Update branch triggers and downstream workflow logic to support all
branches defined in docker-build.yml (main, development, feature/**).
Changes:
docker-build.yml: Expand branch glob to feature/**, use branch-based tags
playwright.yml: Replace is_beta_push with generic is_push detection
security-pr.yml: Same branch-agnostic pattern
supply-chain-pr.yml: Same pattern, skip PR comments for push events
The workflows now support any push that triggers docker-build:
main branch → tag: latest
development branch → tag: dev
feature/* branches → tag: {branch-name}
Pull requests → tag: pr-{number}
Dynamic artifact naming:
Push events: push-image (shared across all branches)
Pull requests: pr-image-{number}
This ensures CI/CD pipelines work for stable releases, bug fixes,
and new feature development without hardcoded branch names.
Implements all 13 fixes identified in the CI/CD audit against
github-actions-ci-cd-best-practices.instructions.md
Critical fixes:
Remove hardcoded encryption key from playwright.yml (security)
Fix artifact filename mismatch in supply-chain-pr.yml (bug)
Pin GoReleaser to ~> v2.5 instead of latest (supply chain)
High priority fixes:
Upgrade CodeQL action from v3 to v4 in supply-chain-pr.yml
Add environment protection for release workflow
Fix shell variable escaping ($$ → $) in release-goreleaser.yml
Medium priority fixes:
Add timeout-minutes to playwright.yml (20 min)
Add explicit permissions to quality-checks.yml
Add timeout-minutes to codecov-upload.yml jobs (15 min)
Fix benchmark.yml permissions (workflow-level read, job-level write)
Low priority fixes:
Add timeout-minutes to docs.yml jobs (10/5 min)
Add permissions block to docker-lint.yml
Add timeout-minutes to renovate.yml (30 min)
Separate PR-specific tests from docker-build.yml into dedicated workflows
that trigger via workflow_run. This creates a cleaner CI architecture where:
playwright.yml: E2E tests triggered after docker-build completes
security-pr.yml: Trivy binary scanning for PRs
supply-chain-pr.yml: SBOM generation + Grype vulnerability scanning
The skip condition used github.ref to detect the beta-release branch,
but for PRs github.ref is "refs/pull/N/merge", not the branch name.
Added github.head_ref to env variables for PR branch detection
Updated condition to check both REF and HEAD_REF
This ensures E2E tests run for PRs from feature/beta-release branch
The DNS provider API endpoints were returning 404 in CI because the
encryption service failed to initialize with an invalid key.
Changed CHARON_ENCRYPTION_KEY from plain text to valid base64 string
Key "dGVzdC1lbmNyeXB0aW9uLWtleS1mb3ItY2ktMzJieXQ=" decodes to 32 bytes
Without valid encryption key, DNS provider routes don't register
This was causing all dns-provider-types.spec.ts tests to fail
Root cause: AES-256-GCM requires exactly 32 bytes for the key
The E2E test "should show script path field when Script type is selected"
was failing because the locator didn't match the actual UI field.
Update locator from /create/i to /script path/i
Update placeholder matcher from /create-dns/i to /dns-challenge.sh/i
Matches actual ScriptProvider field: label="Script Path",
placeholder="/scripts/dns-challenge.sh"
Also includes skill infrastructure for Playwright (separate feature):
Add test-e2e-playwright.SKILL.md for non-interactive test execution
Add run.sh script with argument parsing and report URL output
Add VS Code tasks for skill execution and report viewing
Comprehensive documentation overhaul for Charon features:
Rewrite features.md as marketing overview (87% reduction)
Create comprehensive dns-challenge.md for new DNS feature
Expand 18 feature stub pages into complete documentation:
SSL certificates, CrowdSec, WAF, ACLs, rate limiting
Security headers, proxy headers, web UI, Docker integration
Caddyfile import, logs, WebSocket, backup/restore
Live reload, localization, API, UI themes, supply chain security
Update README.md with DNS Challenge in Top Features
Total: ~2,000+ lines of new user-facing documentation
Refs: #21, #461
Complete documentation overhaul for DNS Challenge Support feature (PR #461):
Rewrite features.md as marketing overview (87% reduction: 1,952 → 249 lines)
Organize features into 8 logical categories with "Learn More" links
Add comprehensive dns-challenge.md with:
15+ supported DNS providers (Cloudflare, Route53, DigitalOcean, etc.)
Step-by-step setup guides
Provider-specific configuration
Manual DNS challenge workflow
Troubleshooting section
Create 18 feature documentation stub pages
Update README.md with DNS Challenge in Top Features section
Refs: #21, #461
- Implement API tests for DNS Provider Types, validating built-in and custom providers.
- Create UI tests for provider selection, ensuring all types are displayed and descriptions are shown.
- Introduce fixtures for consistent test data across DNS Provider tests.
- Update manual DNS provider tests to improve structure and accessibility checks.
Implement Phase 3 of Custom DNS Provider Plugin Support with comprehensive
security controls for external plugin loading.
Add CHARON_PLUGIN_SIGNATURES env var for SHA-256 signature allowlisting
Support permissive (unset), strict ({}), and allowlist modes
Add directory permission verification (reject world-writable)
Configure container with non-root user and read-only plugin mount option
Add 22+ security tests for permissions, signatures, and allowlist logic
Create plugin-security.md operator documentation
Security controls:
Signature verification with sha256: prefix requirement
World-writable directory rejection
Non-root container execution (charon user UID 1000)
Read-only mount support for production deployments
Documented TOCTOU mitigation with atomic deployment workflow
- Created a comprehensive documentation file for DNS provider types, including RFC 2136, Webhook, and Script providers, detailing their use cases, configurations, and security notes.
- Updated the DNSProviderForm component to handle new field types including select and textarea for better user input management.
- Enhanced the DNS provider schemas to include new fields for script execution, webhook authentication, and RFC 2136 configurations, improving flexibility and usability.
Phase 1 of Custom DNS Provider Plugin Support: the /api/v1/dns-providers/types
endpoint now returns types dynamically from the dnsprovider.Global() registry
instead of a hardcoded list.
Backend handler queries registry for all provider types, metadata, and fields
Response includes is_built_in flag to distinguish plugins from built-ins
Frontend types updated with DNSProviderField interface and new response shape
Fixed flaky WAF exclusion test (isolated file-based SQLite DB)
Updated operator docs for registry-driven discovery and plugin installation
Refs: #461