fix(docker): update GeoLite2-Country.mmdb checksum + automation Fixes critical Docker build failure caused by upstream GeoLite2 database update without corresponding Dockerfile checksum update. **Root Cause:** - GeoLite2-Country.mmdb file updated upstream - Dockerfile still referenced old SHA256 checksum - Build aborted at checksum verification (line 352) - Cascade "blob not found" errors for all COPY commands **Changes:** - Update Dockerfile ARG GEOLITE2_COUNTRY_SHA256 to current value - Add automated weekly checksum update workflow (.github/workflows/update-geolite2.yml) - Implement error handling: retry logic, format validation, failure notifications - Document rollback decision matrix with 10 failure scenarios - Create comprehensive maintenance guide (docs/maintenance/geolite2-checksum-update.md) - Update CHANGELOG.md and README.md with maintenance references **Verification:** - Checksum verified against current upstream file: 436135ee... - Pre-commit hooks: PASSED (EOF/whitespace auto-fixed) - Trivy security scan: PASSED (no critical/high issues) - Dockerfile syntax: VALID - GitHub Actions YAML: VALID - No hardcoded secrets or injection vulnerabilities **Automation Features:** - Weekly scheduled checks (Monday 2 AM UTC) - Auto-PR creation when checksum changes - GitHub issue creation on workflow failure - Comprehensive error handling and retry logic **Impact:** - Unblocks all CI/CD Docker image builds - Enables publishing to GHCR/Docker Hub - Prevents future checksum failures via automation - Zero application code changes (no regression risk) **Documentation:** - Implementation plan: docs/plans/geolite2_checksum_fix_spec.md - QA report: docs/reports/qa_geolite2_checksum_fix.md - Maintenance guide: docs/maintenance/geolite2-checksum-update.md **Supervisor Recommendations Implemented:** - #1: Checksum freshness verification before update - #3: Rollback decision criteria (10 scenarios) - #4: Automated workflow error handling Resolves: https://github.com/Wikid82/Charon/actions/runs/21584236523/job/62188372617 COMMIT_MESSAGE_END
docs/issues - Issue Specification Files
This directory contains markdown files that are automatically converted to GitHub Issues when merged to main or development.
How It Works
- Create a markdown file in this directory using the template format
- Add YAML frontmatter with issue metadata (title, labels, priority, etc.)
- Merge to main/development - the
docs-to-issues.ymlworkflow runs - GitHub Issue is created with your specified metadata
- File is moved to
docs/issues/created/to prevent duplicates
Quick Start
Copy _TEMPLATE.md and fill in your issue details:
---
title: "My New Issue"
labels:
- feature
- backend
priority: medium
---
# My New Issue
Description of the issue...
Frontmatter Fields
| Field | Required | Description |
|---|---|---|
title |
Yes* | Issue title (*or uses first H1 as fallback) |
labels |
No | Array of labels to apply |
priority |
No | critical, high, medium, low |
milestone |
No | Milestone name |
assignees |
No | Array of GitHub usernames |
parent_issue |
No | Parent issue number for linking |
create_sub_issues |
No | If true, each ## Section becomes a sub-issue |
Sub-Issues
To create multiple related issues from one file, set create_sub_issues: true:
---
title: "Main Testing Issue"
labels: [testing]
create_sub_issues: true
---
# Main Testing Issue
Overview content for the parent issue.
## Unit Testing
This section becomes a separate issue.
## Integration Testing
This section becomes another separate issue.
Manual Trigger
You can manually run the workflow with:
# Dry run (no issues created)
gh workflow run docs-to-issues.yml -f dry_run=true
# Process specific file
gh workflow run docs-to-issues.yml -f file_path=docs/issues/my-issue.md
Labels
Labels are automatically created if they don't exist. Common labels:
- Priority:
critical,high,medium,low - Type:
feature,bug,enhancement,testing,documentation - Component:
backend,frontend,ui,security,caddy,database