All files renamed from mokocassiopeia to mokoonyx. Update server points to MokoOnyx repo. Bridge migration removed (clean standalone template). Version reset to 01.00.00. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
12 KiB
Workflow Guide - Moko Cassiopeia
Quick reference guide for GitHub Actions workflows and common development tasks.
Table of Contents
Overview
This repository uses GitHub Actions for continuous integration, testing, quality checks, and deployment. All workflows are located in .github/workflows/.
Workflow Execution Model
┌─────────────────┐
│ Code Changes │
└────────┬────────┘
│
▼
┌─────────────────┐
│ CI Pipeline │ ← Validation, Testing, Quality
└────────┬────────┘
│
▼
┌─────────────────┐
│ Version Branch │ ← Create dev/X.Y.Z branch
└────────┬────────┘
│
▼
┌─────────────────┐
│ Release Pipeline│ ← dev → rc → version → main
└────────┬────────┘
│
▼
┌─────────────────┐
│ Distribution │ ← ZIP package + GitHub Release
└─────────────────┘
Workflow Quick Reference
Continuous Integration (ci.yml)
Trigger: Automatic on push/PR to main, dev/, rc/, version/* branches
Purpose: Validates code quality and repository structure
What it does:
- ✅ Validates Joomla manifest XML
- ✅ Checks XML well-formedness
- ✅ Validates GitHub Actions workflows
- ✅ Runs PHP syntax checks
- ✅ Checks for secrets in code
- ✅ Validates license headers
- ✅ Verifies version alignment
When to check: After every commit
How to view results:
# Via GitHub CLI
gh run list --workflow=ci.yml --limit 5
gh run view <run-id> --log
PHP Quality Checks (php_quality.yml)
Trigger: Automatic on push/PR to main, dev/, rc/, version/* branches
Purpose: Ensures PHP code quality and compatibility
What it does:
- 🔍 PHPStan static analysis (level 5)
- 📏 PHP_CodeSniffer with PSR-12 standards
- ✔️ PHP 8.0+ compatibility checks
Matrix: PHP 8.0, 8.1, 8.2, 8.3
When to check: Before committing PHP changes
How to run locally:
# Install tools
composer global require "squizlabs/php_codesniffer:^3.0" --with-all-dependencies
composer global require "phpstan/phpstan:^1.0" --with-all-dependencies
# Run checks
phpcs --standard=phpcs.xml src/
phpstan analyse --configuration=phpstan.neon
Joomla Testing (joomla_testing.yml)
Trigger: Automatic on push/PR to main, dev/, rc/ branches
Purpose: Tests template compatibility with Joomla versions
What it does:
- 📦 Downloads and installs Joomla (4.4, 5.0, 5.1)
- 🔧 Installs template into Joomla
- ✅ Validates template installation
- 🧪 Runs Codeception tests
Matrix: Joomla 4.4/5.0/5.1 × PHP 8.0/8.1/8.2/8.3
When to check: Before releasing new versions
How to test locally:
# See docs/JOOMLA_DEVELOPMENT.md for local testing setup
codecept run
Version Branch Creation (version_branch.yml)
Trigger: Manual workflow dispatch
Purpose: Creates a new version branch and bumps version numbers
What it does:
- 🏷️ Creates dev/, rc/, or version/* branch
- 📝 Updates version in all files
- 📅 Updates manifest dates
- 📋 Moves CHANGELOG unreleased to version
- ✅ Validates version hierarchy
When to use: Starting work on a new version
How to run:
- Go to Actions → Create version branch
- Click "Run workflow"
- Enter version (e.g., 03.06.00)
- Select branch prefix (dev/, rc/, or version/)
- Click "Run workflow"
Example:
new_version: 03.06.00
branch_prefix: dev/
version_text: beta
Release Pipeline (release_pipeline.yml)
Trigger: Manual workflow dispatch or release event
Purpose: Promotes branches through release stages and creates distributions
What it does:
- 🔄 Promotes branches: dev → rc → version → main
- 📅 Normalizes dates in manifest and CHANGELOG
- 📦 Builds distributable ZIP package
- 🚀 Uploads to SFTP server
- 🏷️ Creates Git tag
- 📋 Creates GitHub Release
- 🔒 Attests build provenance
When to use: Promoting a version through release stages
How to run:
- Go to Actions → Release Pipeline
- Click "Run workflow"
- Select classification (auto/rc/stable)
- Click "Run workflow"
Release flow:
dev/X.Y.Z → rc/X.Y.Z → version/X.Y.Z → main
(dev) (RC) (stable) (production)
Deploy to Staging (deploy_staging.yml)
Trigger: Manual workflow dispatch
Purpose: Deploys template to staging/development environments
What it does:
- ✅ Validates deployment prerequisites
- 📦 Builds deployment package
- 🚀 Uploads via SFTP to environment
- 📝 Creates deployment summary
When to use: Testing in staging before production release
How to run:
- Go to Actions → Deploy to Staging
- Click "Run workflow"
- Select environment (staging/development/preview)
- Optionally specify version
- Click "Run workflow"
Required secrets:
STAGING_HOST- SFTP hostnameSTAGING_USER- SFTP usernameSTAGING_KEY- SSH private key (orSTAGING_PASSWORD)STAGING_PATH- Remote deployment path
Repository Health (repo_health.yml)
Trigger: Manual workflow dispatch (admin only)
Purpose: Comprehensive repository health and configuration checks
What it does:
- 🔐 Validates release configuration
- 🌐 Tests SFTP connectivity
- 📂 Checks scripts governance
- 📄 Validates required artifacts
- 🔍 Extended checks (SPDX, ShellCheck, etc.)
When to use: Before major releases or when debugging deployment issues
How to run:
- Go to Actions → Repo Health
- Click "Run workflow"
- Select profile (all/release/repo)
- Click "Run workflow"
Profiles:
all- Run all checksrelease- Release configuration and SFTP onlyscripts- Scripts governance onlyrepo- Repository health only
Common Development Tasks
Starting a New Feature
# 1. Create a new version branch via GitHub Actions
# Actions → Create version branch → dev/X.Y.Z
# 2. Clone and checkout the new branch
git fetch origin
git checkout dev/X.Y.Z
# 3. Make your changes
vim src/index.php
# 4. Validate locally
make validate-required
# 5. Commit and push
git add -A
git commit -m "feat: add new feature"
git push origin dev/X.Y.Z
Running All Validations Locally
# Run comprehensive validation suite
make validate-required
# Run quality checks
make quality
Creating a Release Package
# Package with auto-detected version
```bash
# Package with auto-detected version
make package
# Verify package contents
unzip -l dist/moko-cassiopeia-*.zip
Updating Version Numbers
# Via GitHub Actions (recommended)
# Actions → Release Management workflow
Updating CHANGELOG
Update CHANGELOG.md manually or via pull request following the existing format.
Troubleshooting
CI Failures
PHP Syntax Errors
# Check specific file
php -l src/index.php
# Run validation
make validate-required
Manifest Validation Failed
# Validate manifest and XML files
make validate-required
Version Alignment Issues
# Check version consistency
make validate-required
Workflow Failures
"Branch already exists"
# Check existing branches
git branch -r | grep dev/
# Delete remote branch if needed (carefully!)
git push origin --delete dev/03.06.00
"Missing required secrets"
Go to repository Settings → Secrets and variables → Actions, and add:
FTP_SERVERFTP_USERFTP_KEYorFTP_PASSWORDFTP_PATH
SFTP Connection Failed
-
Verify credentials in repo_health workflow:
- Actions → Repo Health → profile: release
-
Check SSH key format (OpenSSH, not PuTTY PPK)
-
Verify server allows connections from GitHub IPs
Quality Check Failures
PHPStan Errors
# Run locally to see full output
phpstan analyse --configuration=phpstan.neon
# Generate baseline to ignore existing issues
phpstan analyse --configuration=phpstan.neon --generate-baseline
PHPCS Violations
# Check violations
phpcs --standard=phpcs.xml src/
# Auto-fix where possible
phpcbf --standard=phpcs.xml src/
# Show specific error codes
phpcs --standard=phpcs.xml --report=source src/
Joomla Testing Failed
- Check PHP/Joomla version matrix compatibility
- Review MySQL connection errors
- Verify template manifest structure
- Check template file paths
Best Practices
Version Management
- Always use version branches: dev/X.Y.Z, rc/X.Y.Z, version/X.Y.Z
- Follow hierarchy: dev → rc → version → main
- Update CHANGELOG: Document all changes in Unreleased section
- Semantic versioning: Major.Minor.Patch (03.06.00)
Code Quality
- Run validations locally before pushing
- Fix PHPStan warnings at level 5
- Follow PSR-12 coding standards
- Add SPDX license headers to new files
- Keep functions small and well-documented
Workflow Usage
- Use CI for every commit - automated validation
- Run repo_health before releases - comprehensive checks
- Test on staging first - never deploy directly to production
- Monitor workflow runs - fix failures promptly
- Review workflow logs - understand what changed
Release Process
- Create dev branch → Work on features
- Promote to rc → Release candidate testing
- Promote to version → Stable release
- Merge to main → Production (auto-merged via PR)
- Create GitHub Release → Public distribution
Security
- Never commit secrets - use GitHub Secrets
- Use SSH keys for SFTP (not passwords)
- Scan for secrets - runs automatically in CI
- Keep dependencies updated - security patches
- Review security advisories - GitHub Dependabot
Documentation
- Update docs with code - keep in sync
- Document workflow changes - update this guide
- Add examples - show, don't just tell
- Link to relevant docs - cross-reference
- Keep README current - first impression matters
Quick Links
- Main README - Project overview
- Joomla Development Guide - Testing and quality
- CHANGELOG - Version history
- CONTRIBUTING - Contribution guidelines
Getting Help
- Check workflow logs - Most issues have clear error messages
- Review this guide - Common solutions documented
- Run validation scripts - Identify specific issues
- Open an issue - For bugs or questions
- Contact maintainers - For access or configuration issues
Metadata
- Document: docs/WORKFLOW_GUIDE.md
- Repository: https://git.mokoconsulting.tech/MokoConsulting/MokoOnyx
- Path: /docs/WORKFLOW_GUIDE.md
- Owner: Moko Consulting
- Version: 03.06.03
- Status: Active
- Effective Date: 2026-01-30
- Classification: Public Open Source Documentation
Revision History
| Date | Change Summary | Author |
|---|---|---|
| 2026-01-30 | Updated metadata to MokoStandards format | GitHub Copilot |
| 2025-01-04 | Initial workflow guide created | GitHub Copilot |