mirror of
https://github.com/ghndrx/k8s-game-2048.git
synced 2026-02-10 06:45:07 +00:00
🧹 PII Cleanup & Security: - Remove all hardcoded domains (darknex.us, hndrx.co) - Remove all hardcoded emails (admin@ references) - Replace all personal info with environment variables - Repository now 100% generic and reusable 🚀 Fully Automatic Pipeline: - Pipeline now runs automatically develop → staging → production - No manual intervention required for production promotions - Auto-promotion triggers after successful tests - All workflows use commit-specific image tags 🔧 Environment Variables: - All manifests use ${VARIABLE_NAME} syntax - All scripts source from .env file - GitHub Actions use secrets for sensitive data - Complete .env.example template provided 📚 Documentation: - New comprehensive WORKFLOWS.md with pipeline details - New PIPELINE_QUICK_REFERENCE.md for quick reference - Updated all docs to use generic placeholders - Added security/privacy section to README 🔐 Security Enhancements: - Updated .gitignore for all sensitive files - Created PII verification script (verify-pii-removal.sh) - Created cleanup automation script (cleanup-pii.sh) - Repository verified PII-free and production-ready BREAKING: Repository now requires .env configuration - Copy .env.example to .env and configure for your environment - Set GitHub repository secrets for CI/CD workflows - All deployments now use environment-specific configuration
3.8 KiB
3.8 KiB
Contributing to K8s Game 2048
Thank you for considering contributing to this project! This guide will help you get started.
Development Setup
-
Clone the repository
git clone https://github.com/your-username/k8s-game-2048.git cd k8s-game-2048 -
Local Development
# Start local development server npm start # Or with Python python3 -m http.server 8080 --directory src -
Build Docker Image
npm run build # Or docker build -t k8s-game-2048 .
Git Workflow
We use a GitFlow-inspired workflow:
master- Production-ready code, deployed to production automaticallystaging- Staging branch, deployed to staging environment automaticallydevelop- Development branch, deployed to dev environment automaticallyfeature/*- Feature branches, create PR to develophotfix/*- Hotfix branches, create PR to masterrelease/*- Release branches for production deployment
Branch Protection Rules
master: Requires PR review, all checks must passstaging: Requires PR review, all checks must passdevelop: Requires PR review, all checks must pass
Deployment Environments
| Environment | Branch | Domain | Auto-Deploy |
|---|---|---|---|
| Development | develop |
${DEV_DOMAIN} |
✅ |
| Staging | staging |
${STAGING_DOMAIN} |
✅ |
| Production | master |
${PROD_DOMAIN} |
✅ |
Making Changes
For New Features
-
Create a feature branch from
develop:git checkout develop git pull origin develop git checkout -b feature/your-feature-name -
Make your changes and commit:
git add . git commit -m "feat: add your feature description" -
Push and create a PR to
develop:git push origin feature/your-feature-name
For Bug Fixes
-
Create a hotfix branch from
master:git checkout master git pull origin master git checkout -b hotfix/fix-description -
Make your changes and create PR to
master
Commit Convention
We use Conventional Commits:
feat:- New featuresfix:- Bug fixesdocs:- Documentation changesstyle:- Code style changes (formatting, etc.)refactor:- Code refactoringtest:- Adding or updating testschore:- Maintenance tasks
Testing
Local Testing
# Test the game locally
npm start
open http://localhost:8080
Kubernetes Testing
# Deploy to development environment
kubectl apply -f manifests/dev/
# Check deployment status
kubectl get ksvc -n game-2048-dev
# Test the deployed service
curl -f https://${DEV_DOMAIN}/
Code Style
- Use 2 spaces for indentation
- Use meaningful variable and function names
- Add comments for complex logic
- Keep functions small and focused
Pull Request Process
- Title: Use conventional commit format
- Description:
- What changes were made?
- Why were they made?
- How to test the changes?
- Testing: Ensure all environments work correctly
- Documentation: Update README if needed
Release Process
-
Create a release branch from
master:git checkout master git pull origin master git checkout -b release/v1.1.0 -
Update version in
package.json -
Create PR to
master -
After merge, create a GitHub release with tag
-
Production deployment will trigger automatically
Getting Help
- Open an issue for bugs or feature requests
- Start a discussion for questions
- Check existing issues before creating new ones
Code of Conduct
Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.