update
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# shopPRO — Koniec Pracy (release workflow)
|
||||
# shopPRO - Koniec Pracy (release workflow)
|
||||
|
||||
Execute the full release workflow for shopPRO. This is a sequential pipeline — each step depends on the previous one succeeding. Stop and report if any step fails.
|
||||
Execute the full release workflow for shopPRO. This is a sequential pipeline - each step depends on the previous one succeeding. Stop and report if any step fails.
|
||||
|
||||
## Step 1: Run tests
|
||||
|
||||
@@ -8,7 +8,7 @@ Run the full PHPUnit test suite:
|
||||
```bash
|
||||
php phpunit.phar
|
||||
```
|
||||
All tests must pass. If any test fails, stop here — do not proceed to commit. Report the failures and wait for instructions.
|
||||
All tests must pass. If any test fails, stop here - do not proceed to commit. Report the failures and wait for instructions.
|
||||
|
||||
## Step 1b: SonarQube scan
|
||||
|
||||
@@ -19,20 +19,20 @@ sonar-scanner
|
||||
|
||||
After the scan completes, query the SonarQube issues via MCP tool `mcp__sonarqube__issues` with `project_key: "shopPRO"` and `resolved: false`. Fetch all open issues (bugs, vulnerabilities, code smells).
|
||||
|
||||
Then open `docs/TODO.md` and append the found issues at the bottom under a new section:
|
||||
Then open `.paul/docs/TODO.md` and append the found issues at the bottom under a new section:
|
||||
|
||||
```markdown
|
||||
## SonarQube — {VERSION} ({DATE})
|
||||
## SonarQube - {VERSION} ({DATE})
|
||||
|
||||
- [ ] [SEVERITY] FILENAME:LINE — description (rule)
|
||||
- [ ] [SEVERITY] FILENAME:LINE - description (rule)
|
||||
- [ ] ...
|
||||
```
|
||||
|
||||
Rules:
|
||||
- Only add issues that are NOT already present in `docs/TODO.md`
|
||||
- Only add issues that are NOT already present in `.paul/docs/TODO.md`
|
||||
- Group by type: first Bugs/Vulnerabilities, then Code Smells
|
||||
- Skip INFO severity Code Smells — only include MINOR and above
|
||||
- If there are no new issues, write: `## SonarQube — {VERSION} — brak nowych issues`
|
||||
- Skip INFO severity Code Smells - only include MINOR and above
|
||||
- If there are no new issues, write: `## SonarQube - {VERSION} - brak nowych issues`
|
||||
|
||||
## Step 2: Determine version
|
||||
|
||||
@@ -40,24 +40,24 @@ Read the latest git tag to determine the current version number:
|
||||
```bash
|
||||
git tag --sort=-v:refname | head -1
|
||||
```
|
||||
The new version is the previous version incremented by 1 (e.g., v0.333 → v0.334). Use this version number throughout the remaining steps.
|
||||
The new version is the previous version incremented by 1 (e.g., v0.333 -> v0.334). Use this version number throughout the remaining steps.
|
||||
|
||||
## Step 3: Update documentation
|
||||
|
||||
Update these docs files **only if** changes in this session affect them:
|
||||
Update these docs files **only if** changes in this session affect them.
|
||||
Do not update files in root `docs/` directory.
|
||||
|
||||
| File | When to update |
|
||||
|------|---------------|
|
||||
| `docs/CHANGELOG.md` | Always — add a new version entry at the top describing what changed |
|
||||
| `docs/TESTING.md` | If tests were added/removed — update test count and structure |
|
||||
| `CLAUDE.md` | If test count changed — update the "Current suite" line |
|
||||
| `docs/DATABASE_STRUCTURE.md` | If database schema changed |
|
||||
| `docs/PROJECT_STRUCTURE.md` | If architecture/files changed significantly |
|
||||
| `docs/FORM_EDIT_SYSTEM.md` | If form system was modified |
|
||||
| `.paul/docs/CHANGELOG.md` | Always - add a new version entry at the top describing what changed |
|
||||
| `.paul/docs/TESTING.md` | If tests were added/removed - update test count and structure |
|
||||
| `.paul/docs/DB_SCHEMA.md` | If database schema changed |
|
||||
| `.paul/docs/ARCHITECTURE.md` | If architecture/files changed significantly |
|
||||
| `.paul/docs/FORMS.md` | If form system was modified |
|
||||
|
||||
## Step 4: SQL migrations
|
||||
|
||||
If database schema changes were made, create a migration file at `migrations/{version}.sql` (e.g., `migrations/0.334.sql`). Do NOT put SQL files in `updates/` — the build script reads from `migrations/` automatically.
|
||||
If database schema changes were made, create a migration file at `migrations/{version}.sql` (e.g., `migrations/0.334.sql`). Do NOT put SQL files in `updates/` - the build script reads from `migrations/` automatically.
|
||||
|
||||
If no DB changes were made, skip this step.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user