Paul Nothaft
0205c7dcce
Repo transferred from the-luap/picpeak → PicPeak/picpeak. Docker images
publish to ghcr.io/picpeak/picpeak/{backend,frontend} (lowercase, per the
GHCR canonical form computed by docker-build.yml's `${GITHUB_REPOSITORY,,}`).
Sweep covers:
- docker-compose.production.yml + Dockerfiles → new image registry path
- README, CONTRIBUTING, SECURITY, SIMPLE_SETUP, scripts/picpeak-setup.sh
→ new GitHub URLs
- Update-check / release-notes services (updateCheckService,
environmentService, updateNotificationService, adminSystem,
UpdateNotification, githubReleaseUrl) → GitHub API + tag URLs use the
canonical PicPeak/picpeak path
- Issue templates + README-DOCKER + workflow README → updated package URLs
- One commit-context comment in migrations/090 + customerAccountsService
CHANGELOG.md is intentionally untouched (historical release entries are
immutable; GitHub auto-redirects the old URLs indefinitely).
CLAUDE.md keeps the bare `(the-luap)` reference — that's the maintainer's
personal handle, not a repo URL.
22 files, 48/48 line swaps (every change is a 1:1 URL replacement).
5.7 KiB
Contributing to PicPeak
First off, thank you for considering contributing to PicPeak! It's people like you that make PicPeak such a great tool for photographers worldwide.
🤝 Code of Conduct
This project and everyone participating in it is governed by the PicPeak Code of Conduct. By participating, you are expected to uphold this code.
🎯 How Can I Contribute?
Reporting Bugs
Before creating bug reports, please check the existing issues as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible:
- Use a clear and descriptive title
- Describe the exact steps to reproduce the problem
- Provide specific examples to demonstrate the steps
- Describe the behavior you observed and what you expected
- Include screenshots if possible
- Include your environment details (OS, browser, Docker version, etc.)
Suggesting Enhancements
Enhancement suggestions are tracked as GitHub issues. When creating an enhancement suggestion, please include:
- Use a clear and descriptive title
- Provide a detailed description of the suggested enhancement
- Provide specific examples to demonstrate the enhancement
- Describe the current behavior and expected behavior
- Explain why this enhancement would be useful
Your First Code Contribution
Unsure where to begin? You can start by looking through these issues:
- Good first issues - issues which should only require a few lines of code
- Help wanted issues - issues which need extra attention
Pull Requests
- Fork the repo and create your branch from
beta - Install dependencies:
cd backend && npm install cd ../frontend && npm install - Make your changes and ensure:
- Code follows the existing style
- Tests pass:
npm test - Linting passes:
npm run lint
- Write tests if you've added code
- Update documentation if needed
- Create a Pull Request
💻 Development Setup
Prerequisites
- Node.js 18+
- Docker & Docker Compose
- Git
Local Development
# Clone your fork
git clone https://github.com/your-username/picpeak.git
cd picpeak
# Install dependencies
cd backend && npm install
cd ../frontend && npm install
# Set up environment
cp .env.example .env
# Edit .env with your settings
# Start development servers
docker-compose -f docker-compose.dev.yml up
After pulling changes that touch backend/package.json / backend/package-lock.json (or the frontend equivalents), rebuild the affected image so the live-mounted source can require() the new deps:
docker compose -f docker-compose.dev.yml up -d --build backend
# (or `frontend`, or both)
The dev compose bakes node_modules into the image while live-mounting ./backend/src and ./frontend/src from disk. A dep added on disk won't be picked up until the image is rebuilt — typical symptom is a MODULE_NOT_FOUND restart loop on the affected container.
Running Tests
# Backend tests
cd backend && npm test
# Frontend tests
cd frontend && npm test
# E2E tests
npm run test:e2e
📝 Styleguides
Git Commit Messages
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
- Consider starting the commit message with an applicable emoji:
- 🎨
:art:when improving the format/structure of the code - 🐛
:bug:when fixing a bug - 🔥
:fire:when removing code or files - 📝
:memo:when writing docs - 🚀
:rocket:when improving performance - ✨
:sparkles:when adding a new feature
- 🎨
JavaScript/TypeScript Styleguide
- Use ES6+ features
- Prefer async/await over promises
- Use meaningful variable names
- Add JSDoc comments for functions
- Follow ESLint rules
React Styleguide
- Use functional components with hooks
- Keep components small and focused
- Use TypeScript for type safety
- Follow the existing folder structure
- Write tests for new components
📦 Project Structure
picpeak/
├── backend/
│ ├── src/
│ │ ├── routes/ # API endpoints
│ │ ├── services/ # Business logic
│ │ ├── middleware/ # Express middleware
│ │ └── utils/ # Utilities
│ └── migrations/ # Database migrations
├── frontend/
│ ├── src/
│ │ ├── components/ # Reusable components
│ │ ├── pages/ # Page components
│ │ ├── services/ # API services
│ │ └── hooks/ # Custom hooks
│ └── public/ # Static assets
🔄 Release Process
Releases are cut from the beta branch (rolling beta) and promoted to main (stable) on a 4–6 week cadence. release-please handles version bumps, changelog generation, and Docker image publication automatically — contributors don't update package.json or CHANGELOG.md by hand.
See RELEASING.md for the full operational doc (promotion criteria, conflict-resolution checklist for the beta→main merge, hotfix backport path, versioning rules).
📮 Contact
- Create an issue for bugs or features
- Join discussions for questions
- Security issues: Open a security issue on GitHub
Thank you for contributing! 🎉