- helm lint was failing because pack files in .git/ and packages/*.tgz
exceeded the 5MB file size limit
- Add .helmignore to exclude packages/, .git/, .gitea/ and *.tgz files
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Allow empty WP_ADMIN_PASSWORD on initial install for backward compatibility
- Generate secure random password (20 chars) when password is not specified
- During Helm upgrades: Skip installation (WordPress already installed)
- Prevents password mismatch between Kubernetes Secret and WordPress database
Changes:
- Use INSTALL_PASSWORD variable for flexible password handling
- Generate random password with: openssl rand -base64 32 | tr -d "=+/" | cut -c1-20
- Improve logging to distinguish between random generation and manual specification
- Preserve existing database content during upgrades (no password reset)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Previously, when WP_ADMIN_PASSWORD was empty, the init container would
generate a random password and update the Secret. However, Helm upgrades
would start fresh containers and regenerate a new random password, causing
the Secret to not match WordPress's actual admin password.
Changes:
- Remove random password generation logic
- Require WP_ADMIN_PASSWORD to be explicitly set in values.yaml
- Exit with error if password is not provided during installation
- Only install WordPress once when database tables don't exist
- During upgrades, no installation occurs so password remains unchanged
This ensures:
1. Initial deployment: Admin must set WP_ADMIN_PASSWORD in values.yaml
2. Helm upgrades: No password changes occur (WordPress unchanged)
3. Helm rollbacks: Original password still works
4. Secret consistency: Secret always matches WordPress's actual password
Important for users:
- Initial deployment requires WP_ADMIN_PASSWORD in values.yaml
- If not provided, installation will fail with clear error message
- This prevents the password mismatch issue on upgrades
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Refactor the Update values.yaml step to use exact version matching instead of
regex patterns. This approach is simpler, more reliable, and mirrors the
successful implementation in other Helmcharts (e.g., php-fpm).
Changes:
- Extract full current versions using awk (easier to parse)
- Use exact string replacement: sed 's|old_exact_version|new_exact_version|g'
- Only update if version has actually changed (conditional sed)
- Better error handling with set -e
- Clearer logging of what changed
Benefits:
1. Simpler logic: exact match instead of regex patterns
2. More reliable: no regex pattern matching failures
3. Proven approach: matches successful implementation in other projects
4. Clearer intent: code reads like "if version changed, update it"
5. Better debugging: conditional echo statements show exactly what happened
Flow:
1. Get current full version from values.yaml (e.g., 6.9.0-php8.5-fpm-alpine)
2. Get latest version from Docker Hub (shared variable)
3. If different, replace exact old version with exact new version
4. Report what changed (or didn't change)
5. Determine if WordPress version changed for Chart.yaml update decision
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
The complex sed range-based patterns were failing to properly match and
replace Docker image tags in values.yaml. Replace with simpler, more
reliable patterns that directly match the full tag format.
Changes:
- WordPress: Match tag pattern ending with -php[0-9.]*-fpm-alpine
- Nginx: Match tag pattern ending with -alpine-perl
- Simpler single-line patterns reduce complexity and improve reliability
The new patterns:
- WordPress: s|tag: "[0-9.]*-php[0-9.]*-fpm-alpine"|tag: "NEW_VERSION"|
- Nginx: s|tag: "[0-9.]*-alpine-perl"|tag: "NEW_VERSION"|
These patterns are:
1. More specific - only match the intended tag lines
2. Simpler - single sed command per image (no range selection)
3. More reliable - less dependent on surrounding YAML structure
4. Easier to understand and maintain
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Refactor the workflow to use shared variables ($GITHUB_OUTPUT) for version
information, improving code maintainability and reducing redundancy.
Changes:
- Add version_base output to Fetch WordPress step (e.g., "6.9.1")
- Add version_base output to Fetch Nginx step (e.g., "1.29.5")
- Update values.yaml step to use shared variables
- Reference steps.wordpress.outputs.version_base instead of parsing
- Reference steps.wordpress.outputs.version (full tag) and steps.nginx.outputs.version
- Update Increment chart version step
- Use steps.wordpress.outputs.version_base directly for Chart.yaml version
- Eliminate redundant parsing of values.yaml
Benefits:
1. Single source of truth: Version extracted once in fetch steps
2. Reduced code complexity: Eliminate multiple sed/grep operations
3. Better maintainability: Changes to version format only need updating fetch steps
4. Clearer logic: Each step has clear responsibility
5. Improved reliability: Less error-prone than multiple parsing operations
Version flow:
1. Fetch WordPress → outputs: version, version_base
2. Fetch Nginx → outputs: version, version_base
3. Update values.yaml → uses version (full tag)
4. Increment chart version → uses version_base
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Replace complex awk-based parsing with simpler sed-based approach for updating
Docker image tags in values.yaml. The previous awk logic had issues detecting
changes properly.
Changes:
- Use sed for both WordPress and Nginx tag replacements (more reliable)
- Simplify version extraction using sed and cut commands
- Fix backfile creation to avoid overwriting during edits
- Add debug output showing current and new versions
- Improve error handling in diff command (redirect stderr)
The sed approach:
1. Matches the image section (wordpress: or nginx:)
2. Performs substitution until the next top-level key
3. Directly replaces the entire tag value with quotes
This ensures:
- Correct YAML structure preservation
- Reliable change detection
- Accurate version comparison for Chart.yaml update decision
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Enhance the release tag creation and Helm package push procedures:
Create Helm package improvements:
- Add retry logic for git push (up to 3 attempts)
- Rebase on failure to resolve conflicts
- Fail with exit 1 if push ultimately fails (was silently ignored)
- Log success message
Create release tag improvements:
- Check if tag already exists before creating (avoid duplicate creation)
- Add retry logic for tag push (up to 3 attempts)
- Fail with exit 1 if push ultimately fails (prevents silent failures)
- Suppress error output during retry to keep logs clean
- Better logging of tag creation and push success
These changes ensure that:
1. Failed releases don't go unnoticed (exit 1 instead of ignoring)
2. Transient network issues are handled gracefully (retry mechanism)
3. Duplicate tags are avoided
4. Release artifacts are reliably pushed to remote
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
When WordPress version changes, both Chart.yaml fields should be updated to match:
- version: WordPress version (e.g., 6.9.4)
- appVersion: WordPress version (e.g., 6.9.4)
Previously only 'version' was updated while 'appVersion' remained stale.
Changes:
- Extract current appVersion before update
- Update appVersion with sed command (in addition to version)
- Log both version and appVersion changes
This ensures Chart.yaml always reflects the actual WordPress version deployed.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
When WordPress version changes (e.g., 6.9.3 → 6.9.4), Chart.yaml should use
the new WordPress version WITHOUT any suffix.
Suffix (-a, -b, etc.) is only used for multiple releases within the SAME
WordPress version when non-WordPress changes occur.
Changes:
- Simplify Increment chart version step to directly use new WordPress version
- Remove complex suffix handling logic (only needed for non-WordPress updates)
- Extract WordPress version from values.yaml and apply as Chart version
Examples:
- 6.9.3-a + WordPress update → 6.9.4 (no suffix)
- 6.9.4 + Nginx update → 6.9.4-a (suffix added for non-WordPress changes)
- 6.9.4-a + Nginx update → 6.9.4-b (suffix incremented)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Refactor the image-update-and-release workflow to correctly handle Chart.yaml updates:
Changes:
- Add chart_version_update_needed flag in Update values.yaml step
- Compares WordPress version before/after update
- Only sets flag=true if WordPress version actually changed
- Modify Increment chart version step to run only when chart_version_update_needed=true
- Implement proper suffix handling for versions like 6.9.3-a, 6.9.3-b, etc
- Support upgrading base version without suffix to add -a suffix
- Update Commit and push changes step
- Always add values.yaml
- Only add Chart.yaml if WordPress version was updated
- Update Create Helm package and Create release tag steps
- Only run if Chart.yaml was updated (chart_version_update_needed=true)
- Update Summary step to show whether Chart.yaml was updated
This prevents Chart.yaml from being updated when only Nginx or other images change,
avoiding version number regression issues (e.g., 6.9.3 -> 6.9.4 when only Nginx updated).
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Implement a new nginx.forwardRealIP configuration flag to enable/disable
real client IP extraction from X-Forwarded-For headers on bare-metal clusters.
Changes:
- Added nginx.forwardRealIP.enabled flag (default: false) to values.yaml
- Added nginx.forwardRealIP.trustedProxies list for flexible proxy IP ranges
- Updated Nginx configmap to conditionally apply real IP extraction settings
- Updated FastCGI parameters to use real IP when enabled, direct connection IP otherwise
- Updated WordPress wp-config.php to conditionally extract real IPs from headers
Configuration:
- When enabled: Extracts real client IP from X-Forwarded-For header
- When disabled: Uses direct connection IP (default Nginx behavior)
- Supports custom proxy IP ranges for CloudFlare, AWS ALB, etc.
This allows Helmchart to work seamlessly on both:
1. Bare-metal clusters with iptables load balancing
2. Cloud-managed clusters with proper IP forwarding
Version bumped to 6.9.0-a (WordPress version with implementation suffix)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Changed the 'Update values.yaml' step to skip error exit when no version updates
are available. Instead of failing with exit 1, the workflow now logs an INFO
message and continues execution, allowing the workflow to complete successfully
when versions are already up to date.
- Changed ERROR message to INFO message
- Replaced exit 1 with conditional logic
- Added else clause to log when changes are detected
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
