unit test repairs
All checks were successful
Deploy to Test Environment / deploy-to-test (push) Successful in 17m12s
All checks were successful
Deploy to Test Environment / deploy-to-test (push) Successful in 17m12s
This commit is contained in:
108
CLAUDE.md
108
CLAUDE.md
@@ -99,6 +99,26 @@ This prevents linting/type errors from being introduced into the codebase.
|
||||
| `npm run build` | Build for production |
|
||||
| `npm run type-check` | Run TypeScript type checking |
|
||||
|
||||
## Database Schema Files
|
||||
|
||||
**CRITICAL**: The database schema files must be kept in sync with each other. When making schema changes:
|
||||
|
||||
| File | Purpose |
|
||||
| ------------------------------ | ----------------------------------------------------------- |
|
||||
| `sql/master_schema_rollup.sql` | Complete schema used by test database setup and reference |
|
||||
| `sql/initial_schema.sql` | Base schema without seed data, used as standalone reference |
|
||||
| `sql/migrations/*.sql` | Incremental migrations for production database updates |
|
||||
|
||||
**Maintenance Rules:**
|
||||
|
||||
1. **Keep `master_schema_rollup.sql` and `initial_schema.sql` in sync** - These files should contain the same table definitions
|
||||
2. **When adding columns via migration**, also add them to both `master_schema_rollup.sql` and `initial_schema.sql`
|
||||
3. **Migrations are for production deployments** - They use `ALTER TABLE` to add columns incrementally
|
||||
4. **Schema files are for fresh installs** - They define the complete table structure
|
||||
5. **Test database uses `master_schema_rollup.sql`** - If schema files are out of sync with migrations, tests will fail
|
||||
|
||||
**Example:** When `002_expiry_tracking.sql` adds `purchase_date` to `pantry_items`, that column must also exist in the `CREATE TABLE` statements in both `master_schema_rollup.sql` and `initial_schema.sql`.
|
||||
|
||||
## Known Integration Test Issues and Solutions
|
||||
|
||||
This section documents common test issues encountered in integration tests, their root causes, and solutions. These patterns recur frequently.
|
||||
@@ -190,6 +210,94 @@ cb(null, `${file.fieldname}-${uniqueSuffix}-${sanitizedOriginalName}`);
|
||||
|
||||
**Solution:** Use try/catch with graceful degradation or mock the external service checks.
|
||||
|
||||
## Secrets and Environment Variables
|
||||
|
||||
**CRITICAL**: This project uses **Gitea CI/CD secrets** for all sensitive configuration. There is NO `/etc/flyer-crawler/environment` file or similar local config file on the server.
|
||||
|
||||
### Server Directory Structure
|
||||
|
||||
| Path | Environment | Notes |
|
||||
| --------------------------------------------- | ----------- | ------------------------------------------------ |
|
||||
| `/var/www/flyer-crawler.projectium.com/` | Production | NO `.env` file - secrets injected via CI/CD only |
|
||||
| `/var/www/flyer-crawler-test.projectium.com/` | Test | Has `.env.test` file for test-specific config |
|
||||
|
||||
### How Secrets Work
|
||||
|
||||
1. **Gitea Secrets**: All secrets are stored in Gitea repository settings (Settings → Secrets)
|
||||
2. **CI/CD Injection**: Secrets are injected during deployment via `.gitea/workflows/deploy-to-prod.yml` and `deploy-to-test.yml`
|
||||
3. **PM2 Environment**: The CI/CD workflow passes secrets to PM2 via environment variables, which are then available to the application
|
||||
|
||||
### Key Files for Configuration
|
||||
|
||||
| File | Purpose |
|
||||
| ------------------------------------- | ---------------------------------------------------- |
|
||||
| `src/config/env.ts` | Centralized config with Zod schema validation |
|
||||
| `ecosystem.config.cjs` | PM2 process config - reads from `process.env` |
|
||||
| `.gitea/workflows/deploy-to-prod.yml` | Production deployment with secret injection |
|
||||
| `.gitea/workflows/deploy-to-test.yml` | Test deployment with secret injection |
|
||||
| `.env.example` | Template showing all available environment variables |
|
||||
| `.env.test` | Test environment overrides (only on test server) |
|
||||
|
||||
### Adding New Secrets
|
||||
|
||||
To add a new secret (e.g., `SENTRY_DSN`):
|
||||
|
||||
1. Add the secret to Gitea repository settings
|
||||
2. Update the relevant workflow file (e.g., `deploy-to-prod.yml`) to inject it:
|
||||
|
||||
```yaml
|
||||
SENTRY_DSN: ${{ secrets.SENTRY_DSN }}
|
||||
```
|
||||
|
||||
3. Update `ecosystem.config.cjs` to read it from `process.env`
|
||||
4. Update `src/config/env.ts` schema if validation is needed
|
||||
5. Update `.env.example` to document the new variable
|
||||
|
||||
### Current Gitea Secrets
|
||||
|
||||
**Shared (used by both environments):**
|
||||
|
||||
- `DB_HOST`, `DB_USER`, `DB_PASSWORD` - Database credentials
|
||||
- `JWT_SECRET` - Authentication
|
||||
- `GOOGLE_MAPS_API_KEY` - Google Maps
|
||||
- `GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET` - Google OAuth
|
||||
- `GH_CLIENT_ID`, `GH_CLIENT_SECRET` - GitHub OAuth
|
||||
|
||||
**Production-specific:**
|
||||
|
||||
- `DB_DATABASE_PROD` - Production database name
|
||||
- `REDIS_PASSWORD_PROD` - Redis password (uses database 0)
|
||||
- `VITE_GOOGLE_GENAI_API_KEY` - Gemini API key for production
|
||||
- `SENTRY_DSN`, `VITE_SENTRY_DSN` - Bugsink error tracking DSNs (production projects)
|
||||
|
||||
**Test-specific:**
|
||||
|
||||
- `DB_DATABASE_TEST` - Test database name
|
||||
- `REDIS_PASSWORD_TEST` - Redis password (uses database 1 for isolation)
|
||||
- `VITE_GOOGLE_GENAI_API_KEY_TEST` - Gemini API key for test
|
||||
- `SENTRY_DSN_TEST`, `VITE_SENTRY_DSN_TEST` - Bugsink error tracking DSNs (test projects)
|
||||
|
||||
### Test Environment
|
||||
|
||||
The test environment (`flyer-crawler-test.projectium.com`) uses **both** Gitea CI/CD secrets and a local `.env.test` file:
|
||||
|
||||
- **Gitea secrets**: Injected during deployment via `.gitea/workflows/deploy-to-test.yml`
|
||||
- **`.env.test` file**: Located at `/var/www/flyer-crawler-test.projectium.com/.env.test` for local overrides
|
||||
- **Redis database 1**: Isolates test job queues from production (which uses database 0)
|
||||
- **PM2 process names**: Suffixed with `-test` (e.g., `flyer-crawler-api-test`)
|
||||
|
||||
### Dev Container Environment
|
||||
|
||||
The dev container runs its own **local Bugsink instance** - it does NOT connect to the production Bugsink server:
|
||||
|
||||
- **Local Bugsink**: Runs at `http://localhost:8000` inside the container
|
||||
- **Pre-configured DSNs**: Set in `compose.dev.yml`, pointing to local instance
|
||||
- **Admin credentials**: `admin@localhost` / `admin`
|
||||
- **Isolated**: Dev errors stay local, don't pollute production/test dashboards
|
||||
- **No Gitea secrets needed**: Everything is self-contained in the container
|
||||
|
||||
---
|
||||
|
||||
## MCP Servers
|
||||
|
||||
The following MCP servers are configured for this project:
|
||||
|
||||
Reference in New Issue
Block a user