feat(p5): ci/cd + docker + sonarqube + relatorio iteracao 4#191
Merged
Conversation
Tarefa P5 (Eng Software II, iteracao 4): - coverage: excluir src/components/ui/** (shadcn/Radix wrappers) do coverage unitario + SonarQube exclusions. Branch coverage 79.65% -> 84.53%. Closes #188 - docker: docker-compose.yml (postgres:16 + node:22 dev com migrate/seed) Closes #189 - docs: docs/doc-deploy.md (deploy Vercel + compose + CI + SemVer + Conventional Commits) docs/sonarqube/config.md + docs/sonarqube/scans.md (setup + cadencia 2x/semana) Closes #190 - ci: cron schedule 2x/semana (3 9 * * 1,4) + workflow_dispatch no ci.yml - relatorio: docs/relatorio-testes.md iteracao 3 -> 4 (P5), US13 PRD-8 (#187) como US do membro (tela ao banco), metricas 84.53% branch, bugs #188-190 - issues: criadas e fechadas #188 #189 #190 Gates: typecheck 0 errors, lint 0 errors, 1137/1137 tests, branch 84.53% (>=80% P5). Refs: tarefa P5 https://github.com/tacianosilva/eng-software-2/blob/main/tarefas/projetos/P5-tarefa5.md Co-Authored-By: Claude <noreply@anthropic.com>
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 34608088 | Triggered | Generic Password | bc429b0 | docker-compose.yml | View secret |
| 34608088 | Triggered | Generic Password | bc429b0 | docker-compose.yml | View secret |
| 34608088 | Triggered | Generic Password | bc429b0 | docker-compose.yml | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
ECC bundle files are already tracked in this repository. Skipping generation of another bundle PR. |
WalkthroughThis PR excludes shadcn/ui component wrappers from unit test coverage measurement (Vitest and SonarQube), adds a docker-compose.yml for local Postgres/Node development, introduces SonarQube configuration and scan-log documentation with a CI cron schedule, and updates the test report with refreshed metrics and bug tracking. ChangesCoverage exclusions, Docker setup, and Sonar documentation
Estimated code review effort: 2 (Simple) | ~12 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Refs: P5-tarefa5 Co-Authored-By: Claude <noreply@anthropic.com>
Contributor
|
ECC bundle files are already tracked in this repository. Skipping generation of another bundle PR. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (1)
docker-compose.yml (1)
24-40: 🩺 Stability & Availability | 🔵 Trivial | 💤 Low valueNo healthcheck or restart policy on the
appservice.The
dbservice hasrestart: unless-stoppedand a healthcheck, butapphas neither. If the container crashes (e.g., from a transient migration error), it won't restart automatically, unlikedb.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker-compose.yml` around lines 24 - 40, The app service in docker-compose.yml is missing resilience settings compared to db. Add an appropriate restart policy to the app service so it recovers from transient crashes, and consider adding a healthcheck if needed so its readiness can be tracked consistently. Update the app service definition near the existing container_name, depends_on, and command settings.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docker-compose.yml`:
- Around line 11-13: GitGuardian is flagging the inline `POSTGRES_PASSWORD`
default in the compose config and the same value reused in the connection
strings. Update the `docker-compose` setup to remove the baked-in `postgres`
fallback and source credentials from environment-only values (document the
required keys in an `.env.example` if needed), then make sure the DB service and
any connection URLs continue to reference the same
`POSTGRES_USER`/`POSTGRES_PASSWORD`/`POSTGRES_DB` variables. If this is
confirmed as local-dev only, add a targeted GitGuardian ignore rule instead of
keeping the hardcoded default.
In `@docs/relatorio-testes.md`:
- Around line 249-258: The bug table entry for `#190` is missing one shipped Sonar
documentation deliverable. Update the row in relatorio-testes.md so it lists all
created docs for that item, including docs/sonarqube/scans.md alongside the
existing docs/doc-deploy.md and docs/sonarqube/config.md, and keep the summary
aligned with the actual PR artifacts.
- Around line 13-21: Reword the opening summary in relatorio-testes.md so it no
longer states that P5 is fully complete; update the phrasing to distinguish what
was actually completed (unit/E2E tests, Docker, Vercel, Quality Gate) from what
is still scheduled or conditional, especially the pending SonarQube execution
marked in the table and the coverage result that depends on excluding
src/components/ui/**. Keep the table intact, but make the narrative clearly
reflect completed work versus adjusted metrics and pending cadence items.
In `@docs/sonarqube/config.md`:
- Around line 21-24: The `sonar.test.inclusions` entry uses shorthand glob
notation instead of the exact patterns from `sonar-project.properties`; update
the table so it mirrors the real Sonar config patterns verbatim. Adjust the
`sonar.test.inclusions` row in `docs/sonarqube/config.md` to match the same
test-file globs used by the property file, keeping the `sonar.test.inclusions`
key and its examples aligned with the actual configured values.
- Around line 50-76: The cron example in the SonarQube docs is out of sync with
the GitHub Actions schedule used by the workflow. Update the scheduling snippet
in the “Cadência semanal” section so it matches the actual `schedule` cron used
by the `sonar` job in `.github/workflows/ci.yml`, keeping the documented time
and weekdays consistent with the workflow.
In `@docs/sonarqube/scans.md`:
- Around line 9-11: Update the “Próxima execução” entry in scans.md so the
next-execution date matches the cron schedule; the current date is incorrect for
the `3 9 * * 1,4` scan timing. Adjust the date shown in the “Próxima execução”
bullet to the next Thursday run after 2026-07-06, and keep the existing schedule
reference in the same entry.
---
Nitpick comments:
In `@docker-compose.yml`:
- Around line 24-40: The app service in docker-compose.yml is missing resilience
settings compared to db. Add an appropriate restart policy to the app service so
it recovers from transient crashes, and consider adding a healthcheck if needed
so its readiness can be tracked consistently. Update the app service definition
near the existing container_name, depends_on, and command settings.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c3f58568-8dcd-46e3-b99d-366940fa409d
📒 Files selected for processing (7)
.github/workflows/ci.ymldocker-compose.ymldocs/relatorio-testes.mddocs/sonarqube/config.mddocs/sonarqube/scans.mdsonar-project.propertiesvitest.config.ts
Comment on lines
+11
to
+13
| POSTGRES_USER: ${POSTGRES_USER:-postgres} | ||
| POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres} | ||
| POSTGRES_DB: ${POSTGRES_DB:-pweb} |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
Address GitGuardian secret detection.
The pipeline flagged hardcoded secrets at these lines. The postgres fallback password baked into POSTGRES_PASSWORD and reused in the connection strings is what GitGuardian's scanner is matching against, even though this is only a local-dev default.
Consider dropping the inline fallback and requiring credentials from a .env file (with an .env.example documenting the expected keys), or adding a GitGuardian ignore rule for this specific finding if it's confirmed as a false positive for local dev tooling.
🔒️ Suggested fix
environment:
- POSTGRES_USER: ${POSTGRES_USER:-postgres}
- POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres}
+ POSTGRES_USER: ${POSTGRES_USER}
+ POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${POSTGRES_DB:-pweb}Also applies to: 32-33
🧰 Tools
🪛 GitHub Check: GitGuardian Security Checks
[error] 12-12: GitGuardian triggered: hardcoded secret detected (Generic Password). GitGuardian id: 34608088. Commit: bc429b0.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose.yml` around lines 11 - 13, GitGuardian is flagging the inline
`POSTGRES_PASSWORD` default in the compose config and the same value reused in
the connection strings. Update the `docker-compose` setup to remove the baked-in
`postgres` fallback and source credentials from environment-only values
(document the required keys in an `.env.example` if needed), then make sure the
DB service and any connection URLs continue to reference the same
`POSTGRES_USER`/`POSTGRES_PASSWORD`/`POSTGRES_DB` variables. If this is
confirmed as local-dev only, add a targeted GitGuardian ignore rule instead of
keeping the hardcoded default.
Source: Pipeline failures
Comment on lines
+21
to
+24
| | `sonar.javascript.lcov.reportPaths` | `coverage/lcov.info` | relatório LCOV gerado pelo Vitest | | ||
| | `sonar.exclusions` | testes, coverage, node_modules, `src/components/ui/**` | shadcn/Radix wrappers não são lógica de negócio | | ||
| | `sonar.tests` | `src` | diretório raiz de testes | | ||
| | `sonar.test.inclusions` | `src/**/*.test.ts(x)`, `**.spec.ts(x)` | arquivos de teste | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Use the exact test-glob patterns from sonar-project.properties.
src/**/*.test.ts(x) / **.spec.ts(x) are shorthand, not the actual patterns in the Sonar config. If someone copies this table into config, they can end up with a broken inclusion list.
♻️ Proposed fix
-| `sonar.test.inclusions` | `src/**/*.test.ts(x)`, `**.spec.ts(x)` | arquivos de teste |
+| `sonar.test.inclusions` | `src/**/*.test.ts`, `src/**/*.test.tsx`, `src/**/*.spec.ts`, `src/**/*.spec.tsx` | arquivos de teste |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| | `sonar.javascript.lcov.reportPaths` | `coverage/lcov.info` | relatório LCOV gerado pelo Vitest | | |
| | `sonar.exclusions` | testes, coverage, node_modules, `src/components/ui/**` | shadcn/Radix wrappers não são lógica de negócio | | |
| | `sonar.tests` | `src` | diretório raiz de testes | | |
| | `sonar.test.inclusions` | `src/**/*.test.ts(x)`, `**.spec.ts(x)` | arquivos de teste | | |
| | `sonar.javascript.lcov.reportPaths` | `coverage/lcov.info` | relatório LCOV gerado pelo Vitest | | |
| | `sonar.exclusions` | testes, coverage, node_modules, `src/components/ui/**` | shadcn/Radix wrappers não são lógica de negócio | | |
| | `sonar.tests` | `src` | diretório raiz de testes | | |
| | `sonar.test.inclusions` | `src/**/*.test.ts`, `src/**/*.test.tsx`, `src/**/*.spec.ts`, `src/**/*.spec.tsx` | arquivos de teste | |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~22-~22: Quando não estão acompanhadas de vocativo, as interjeições devem ser finalizadas com pontos de exclamação ou interrogação. Quando houver vocativo, deve usar a vírgula. Para indicar hesitação ou prolongamento de ideias, utilize as reticências.
Context: ... | testes, coverage, node_modules, src/components/ui/** | shadcn/Radix wrappers não são lógi...
(INTERJECTIONS_PUNTUATION)
[grammar] ~23-~23: Possível erro de concordância.
Context: ... | diretório raiz de testes | | `s...
(GENERAL_GENDER_AGREEMENT_ERRORS)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/sonarqube/config.md` around lines 21 - 24, The `sonar.test.inclusions`
entry uses shorthand glob notation instead of the exact patterns from
`sonar-project.properties`; update the table so it mirrors the real Sonar config
patterns verbatim. Adjust the `sonar.test.inclusions` row in
`docs/sonarqube/config.md` to match the same test-file globs used by the
property file, keeping the `sonar.test.inclusions` key and its examples aligned
with the actual configured values.
Comment on lines
+9
to
+11
| ## Próxima execução | ||
|
|
||
| - 2026-07-10 (qui) — scan mid-week via cron `3 9 * * 1,4`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Fix the next-execution date.
2026-07-10 is a Friday, not a Thursday. With the 3 9 * * 1,4 schedule, the next Thursday run after 2026-07-06 is 2026-07-09.
♻️ Proposed fix
-- 2026-07-10 (qui) — scan mid-week via cron `3 9 * * 1,4`.
+- 2026-07-09 (qui) — scan mid-week via cron `3 9 * * 1,4`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## Próxima execução | |
| - 2026-07-10 (qui) — scan mid-week via cron `3 9 * * 1,4`. | |
| ## Próxima execução | |
| - 2026-07-09 (qui) — scan mid-week via cron `3 9 * * 1,4`. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/sonarqube/scans.md` around lines 9 - 11, Update the “Próxima execução”
entry in scans.md so the next-execution date matches the cron schedule; the
current date is incorrect for the `3 9 * * 1,4` scan timing. Adjust the date
shown in the “Próxima execução” bullet to the next Thursday run after
2026-07-06, and keep the existing schedule reference in the same entry.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="docs/CURRENT-STATE.md">
<violation number="1" location="docs/CURRENT-STATE.md:23">
P2: The date `2026-07-10` is a Friday, not a Thursday. The cron schedule `3 9 * * 1,4` fires on Mondays (1) and Thursdays (4), so a Friday execution will never occur. The next Thursday after 2026-07-06 is `2026-07-09`.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
|
||
| ### Pendências P5 | ||
|
|
||
| - 2ª execução SonarQube (2026-07-10, cron automático). |
There was a problem hiding this comment.
P2: The date 2026-07-10 is a Friday, not a Thursday. The cron schedule 3 9 * * 1,4 fires on Mondays (1) and Thursdays (4), so a Friday execution will never occur. The next Thursday after 2026-07-06 is 2026-07-09.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/CURRENT-STATE.md, line 23:
<comment>The date `2026-07-10` is a Friday, not a Thursday. The cron schedule `3 9 * * 1,4` fires on Mondays (1) and Thursdays (4), so a Friday execution will never occur. The next Thursday after 2026-07-06 is `2026-07-09`.</comment>
<file context>
@@ -1,5 +1,30 @@
+
+### Pendências P5
+
+- 2ª execução SonarQube (2026-07-10, cron automático).
+- SonarCloud action pré-existente usa tag `v2.89.0` (Semgrep WARNING pin SHA) — fora escopo P5.
+
</file context>
Suggested change
| - 2ª execução SonarQube (2026-07-10, cron automático). | |
| - 2ª execução SonarQube (2026-07-09, cron automático). |
Tabela 1 Execucao: Testes 01-03 mapeiam fluxos A1 mobile, A2 desktop, A3 paridade da US13 PRD-8 PR #187. Tabela 2 Providencias: Testes 04-06 P5 infra (cobertura #188, docker #189, docs #190) tipados. A3.2 discrimina colunas por tabela (Matriculas vs Pagamentos sem status). E2E enrollment.spec.ts cobre /alunos/[id]. Honra formato 2-tabelas da disciplina EngSoftware II. Co-Authored-By: Claude <noreply@anthropic.com>
Contributor
|
ECC bundle files are already tracked in this repository. Skipping generation of another bundle PR. |
There was a problem hiding this comment.
15 issues found and verified against the latest diff
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="docs/sonarqube/scans.md">
<violation number="1" location="docs/sonarqube/scans.md:15">
P3: The documentation refers to `SonarCloud Scan` as a "CI job", but in `.github/workflows/ci.yml` it is a step inside the `test` job ("Tests & Coverage"), not a standalone job. This could confuse readers looking for a separate job in the workflow or misidentifying where scan results and artifacts reside. Consider changing "CI job" to "CI step" so the instructions match the actual workflow structure.</violation>
</file>
<file name="sonar-project.properties">
<violation number="1" location="sonar-project.properties:16">
P1: Using `sonar.exclusions` to exclude `src/components/ui/**` removes these files from **all** SonarCloud analysis — not just coverage, but also bug detection, vulnerability scanning, code smells, duplication checks, and maintainability metrics. Since the PR intent is only to improve branch coverage numbers (described as excluding lib wrappers), using `sonar.coverage.exclusions` instead limits the exclusion to coverage while preserving quality analysis on those 74 component files.</violation>
</file>
<file name="docs/sonarqube/config.md">
<violation number="1" location="docs/sonarqube/config.md:24">
P2: The documented `sonar.test.inclusions` values use `ts(x)` shorthand, but SonarScanner properties use simple wildcard patterns (`*`, `**`, `?`) where parenthetical groups are not supported. If someone copies these documented globs into `sonar-project.properties`, `.test.ts` and `.test.tsx` files won't be matched correctly, which can break test indexing and coverage classification. It would be good to align the documentation with the actual property file syntax — either by listing the comma-separated patterns explicitly (as done in `sonar-project.properties`) or by using `*.test.ts*` which the wildcard syntax does support.</violation>
<violation number="2" location="docs/sonarqube/config.md:45">
P2: The local SonarScanner runbook uses the deprecated `sonar.login` property for authentication. SonarSource replaced this with `sonar.token` in 2023 and has announced that `sonar.login` will be removed from SonarQube Cloud on June 11, 2026, after which scans using it will fail to authenticate. Updating the instructions to `-Dsonar.token=$SONAR_TOKEN` keeps the runbook aligned with current scanner guidance and avoids future breakage.</violation>
<violation number="3" location="docs/sonarqube/config.md:50">
P2: The CI documentation describes a `sonar` job that does not exist and a shell-based scan step that is not what the workflow actually uses. In `.github/workflows/ci.yml`, the SonarCloud scan is a step inside the `test` job using `SonarSource/sonarqube-scan-action`, not a separate `sonar` job running `sonar-scanner`. This mismatch will mislead anyone trying to debug or update the scan configuration. Updating section 5 to match the real `test` job and action-based step would keep the runbook accurate.</violation>
<violation number="4" location="docs/sonarqube/config.md:74">
P2: The documented cron schedule (`0 9 * * 1,4`) doesn't match the actual schedule in `.github/workflows/ci.yml` (`3 9 * * 1,4`). This cross-file inconsistency could mislead maintainers copying the snippet.</violation>
<violation number="5" location="docs/sonarqube/config.md:84">
P2: The metrics table reports `0` current code smells, but the next paragraph documents `16 smells` as known pending items in `docs/TECHNICAL-DEBT.md`. Even if those 16 are marked as false positives, the proximity creates a contradiction for readers: the table suggests zero total smells while the text confirms 16 documented ones exist. To avoid misrepresenting the project's quality baseline, consider clarifying the `Atual` value as `0 (unresolved)` or `0 ativos`, and add a brief note in the same row or immediately after explaining that 16 additional smells are documented as false positives and do not count toward the current unresolved total.</violation>
</file>
<file name="docker-compose.yml">
<violation number="1" location="docker-compose.yml:8">
P2: Hard-coded `container_name` values on both services prevent Docker Compose from namespacing containers by project. This blocks running multiple concurrent Compose instances (e.g., different branches, CI jobs, or shared dev hosts) and breaks Compose scaling behavior. Since there are no other references to `pweb_db` or `pweb_app` elsewhere in the repo, these explicit names aren't required for cross-referencing. Removing `container_name` from both services lets Compose generate safe, unique names automatically.</violation>
<violation number="2" location="docker-compose.yml:12">
P2: GitGuardian flagged this hardcoded default password. While it's a local-dev compose file, the inline fallback `postgres` triggers secret scanners and could be inadvertently used in non-local environments. Consider requiring credentials from a `.env` file (with an `.env.example` documenting the expected keys) or adding a GitGuardian ignore annotation for this file.</violation>
<violation number="3" location="docker-compose.yml:15">
P1: The database service is published on the host port without an explicit bind address and falls back to the well-known default password `postgres`. Docker Compose port mappings without a bind address listen on all interfaces (`0.0.0.0`), so if this stack is run on a VM or any host with a public network interface, PostgreSQL becomes externally reachable with a default credential. Consider restricting the port binding to localhost: `127.0.0.1:${POSTGRES_PORT:-5432}:5432`. It is also worth evaluating whether a hard-coded default superuser password should be provided at all.</violation>
<violation number="4" location="docker-compose.yml:17">
P2: The `pweb_pgdata` volume persists the Postgres data directory, so `POSTGRES_USER`, `POSTGRES_PASSWORD`, and `POSTGRES_DB` are only applied on the very first initialization. If anyone changes those environment values later, the app’s `DATABASE_URL` will immediately reference new credentials that don’t exist in the persisted database, causing confusing connection and migration failures. Consider adding a comment warning that changes to these variables require recreating the volume (`docker volume rm pweb_pgdata`).</violation>
<violation number="5" location="docker-compose.yml:25">
P2: Because the `app` service bind-mounts the host repository and runs as root, generated files (`.next/`, `node_modules/.prisma/`, updated lockfiles, etc.) are created as `root` on Linux hosts. This causes local permission issues when developers later need to edit or remove those files.
You can avoid this by running the container with the host user's UID/GID, for example by adding `user: "${UID:-1000}:${GID:-1000}"` to the service and starting Compose with `UID=$(id -u) GID=$(id -g) docker compose up`. Alternatively, a custom image that creates and switches to a non-root user with matching ownership would also work.</violation>
<violation number="6" location="docker-compose.yml:32">
P2: The `DATABASE_URL` and `DIRECT_URL` connection strings are constructed by directly interpolating `POSTGRES_PASSWORD` and other fields, which means any special URI characters (`@`, `:`, `#`, `?`) in those values will produce an unparseable connection string. For example, a password like `p@ss#123` breaks Prisma/libpq URL parsing because `#` is treated as a URI fragment anchor and `?` conflicts with the `schema=public` query parameter. The database container itself will still initialize correctly because it receives the raw `POSTGRES_PASSWORD` value, but the app container will fail to connect. Consider allowing developers to supply pre-encoded `DATABASE_URL`/`DIRECT_URL` values directly as environment variables, falling back to the composed URL only when they are not explicitly provided.</violation>
<violation number="7" location="docker-compose.yml:34">
P1: The container is explicitly a development environment (runs `npm run dev`, Prisma migrations, and seeding), yet it allows the host to override `NODE_ENV`. If an external shell sets `NODE_ENV=production`, `npm install` will skip devDependencies by default, and both `prisma` and `tsx` (which are in `devDependencies`) won't be installed on disk. This will cause `npx prisma migrate deploy` and the seed step to fail immediately on container start. Since this compose file is only for local development, consider hardcoding `NODE_ENV: development` instead of allowing a host override.</violation>
<violation number="8" location="docker-compose.yml:36">
P3: The app service port mapping binds to all host interfaces by default, making the Next.js development server reachable from the entire local network. Since this is a development environment running `npm run dev`, it may expose debugging endpoints, source maps, or verbose errors beyond localhost. Consider restricting the binding to `127.0.0.1` unless LAN access is intentionally needed: `127.0.0.1:${APP_PORT:-3000}:3000`.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| # Test coverage reporting | ||
| sonar.javascript.lcov.reportPaths=coverage/lcov.info | ||
| sonar.exclusions=src/**/*.test.ts,src/**/*.test.tsx,src/**/*.spec.ts,src/**/*.spec.tsx,src/test/**,coverage/**,node_modules/** | ||
| sonar.exclusions=src/**/*.test.ts,src/**/*.test.tsx,src/**/*.spec.ts,src/**/*.spec.tsx,src/test/**,coverage/**,node_modules/**,src/components/ui/** |
There was a problem hiding this comment.
P1: Using sonar.exclusions to exclude src/components/ui/** removes these files from all SonarCloud analysis — not just coverage, but also bug detection, vulnerability scanning, code smells, duplication checks, and maintainability metrics. Since the PR intent is only to improve branch coverage numbers (described as excluding lib wrappers), using sonar.coverage.exclusions instead limits the exclusion to coverage while preserving quality analysis on those 74 component files.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At sonar-project.properties, line 16:
<comment>Using `sonar.exclusions` to exclude `src/components/ui/**` removes these files from **all** SonarCloud analysis — not just coverage, but also bug detection, vulnerability scanning, code smells, duplication checks, and maintainability metrics. Since the PR intent is only to improve branch coverage numbers (described as excluding lib wrappers), using `sonar.coverage.exclusions` instead limits the exclusion to coverage while preserving quality analysis on those 74 component files.</comment>
<file context>
@@ -13,6 +13,6 @@ sonar.organization=emiyakiritsugu3
# Test coverage reporting
sonar.javascript.lcov.reportPaths=coverage/lcov.info
-sonar.exclusions=src/**/*.test.ts,src/**/*.test.tsx,src/**/*.spec.ts,src/**/*.spec.tsx,src/test/**,coverage/**,node_modules/**
+sonar.exclusions=src/**/*.test.ts,src/**/*.test.tsx,src/**/*.spec.ts,src/**/*.spec.tsx,src/test/**,coverage/**,node_modules/**,src/components/ui/**
sonar.tests=src
sonar.test.inclusions=src/**/*.test.ts,src/**/*.test.tsx,src/**/*.spec.ts,src/**/*.spec.tsx
</file context>
Suggested change
| sonar.exclusions=src/**/*.test.ts,src/**/*.test.tsx,src/**/*.spec.ts,src/**/*.spec.tsx,src/test/**,coverage/**,node_modules/**,src/components/ui/** | |
| sonar.exclusions=src/**/*.test.ts,src/**/*.test.tsx,src/**/*.spec.ts,src/**/*.spec.tsx,src/test/**,coverage/**,node_modules/** | |
| sonar.coverage.exclusions=src/components/ui/** |
| environment: | ||
| DATABASE_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public | ||
| DIRECT_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public | ||
| NODE_ENV: ${NODE_ENV:-development} |
There was a problem hiding this comment.
P1: The container is explicitly a development environment (runs npm run dev, Prisma migrations, and seeding), yet it allows the host to override NODE_ENV. If an external shell sets NODE_ENV=production, npm install will skip devDependencies by default, and both prisma and tsx (which are in devDependencies) won't be installed on disk. This will cause npx prisma migrate deploy and the seed step to fail immediately on container start. Since this compose file is only for local development, consider hardcoding NODE_ENV: development instead of allowing a host override.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docker-compose.yml, line 34:
<comment>The container is explicitly a development environment (runs `npm run dev`, Prisma migrations, and seeding), yet it allows the host to override `NODE_ENV`. If an external shell sets `NODE_ENV=production`, `npm install` will skip devDependencies by default, and both `prisma` and `tsx` (which are in `devDependencies`) won't be installed on disk. This will cause `npx prisma migrate deploy` and the seed step to fail immediately on container start. Since this compose file is only for local development, consider hardcoding `NODE_ENV: development` instead of allowing a host override.</comment>
<file context>
@@ -0,0 +1,44 @@
+ environment:
+ DATABASE_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public
+ DIRECT_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public
+ NODE_ENV: ${NODE_ENV:-development}
+ ports:
+ - '${APP_PORT:-3000}:3000'
</file context>
| POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres} | ||
| POSTGRES_DB: ${POSTGRES_DB:-pweb} | ||
| ports: | ||
| - '${POSTGRES_PORT:-5432}:5432' |
There was a problem hiding this comment.
P1: The database service is published on the host port without an explicit bind address and falls back to the well-known default password postgres. Docker Compose port mappings without a bind address listen on all interfaces (0.0.0.0), so if this stack is run on a VM or any host with a public network interface, PostgreSQL becomes externally reachable with a default credential. Consider restricting the port binding to localhost: 127.0.0.1:${POSTGRES_PORT:-5432}:5432. It is also worth evaluating whether a hard-coded default superuser password should be provided at all.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docker-compose.yml, line 15:
<comment>The database service is published on the host port without an explicit bind address and falls back to the well-known default password `postgres`. Docker Compose port mappings without a bind address listen on all interfaces (`0.0.0.0`), so if this stack is run on a VM or any host with a public network interface, PostgreSQL becomes externally reachable with a default credential. Consider restricting the port binding to localhost: `127.0.0.1:${POSTGRES_PORT:-5432}:5432`. It is also worth evaluating whether a hard-coded default superuser password should be provided at all.</comment>
<file context>
@@ -0,0 +1,44 @@
+ POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres}
+ POSTGRES_DB: ${POSTGRES_DB:-pweb}
+ ports:
+ - '${POSTGRES_PORT:-5432}:5432'
+ volumes:
+ - pweb_pgdata:/var/lib/postgresql/data
</file context>
|
|
||
| Saída: link para o dashboard SonarCloud com o novo scan. | ||
|
|
||
| ## 5. CI (GitHub Actions) |
There was a problem hiding this comment.
P2: The CI documentation describes a sonar job that does not exist and a shell-based scan step that is not what the workflow actually uses. In .github/workflows/ci.yml, the SonarCloud scan is a step inside the test job using SonarSource/sonarqube-scan-action, not a separate sonar job running sonar-scanner. This mismatch will mislead anyone trying to debug or update the scan configuration. Updating section 5 to match the real test job and action-based step would keep the runbook accurate.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/sonarqube/config.md, line 50:
<comment>The CI documentation describes a `sonar` job that does not exist and a shell-based scan step that is not what the workflow actually uses. In `.github/workflows/ci.yml`, the SonarCloud scan is a step inside the `test` job using `SonarSource/sonarqube-scan-action`, not a separate `sonar` job running `sonar-scanner`. This mismatch will mislead anyone trying to debug or update the scan configuration. Updating section 5 to match the real `test` job and action-based step would keep the runbook accurate.</comment>
<file context>
@@ -0,0 +1,114 @@
+
+Saída: link para o dashboard SonarCloud com o novo scan.
+
+## 5. CI (GitHub Actions)
+
+Job `sonar` no `.github/workflows/ci.yml` (quando `SONAR_TOKEN` presente):
</file context>
| sonar-scanner \ | ||
| -Dsonar.projectKey=EmiyaKiritsugu3_PWeb_Project \ | ||
| -Dsonar.organization=emiyakiritsugu3 \ | ||
| -Dsonar.login=$SONAR_TOKEN |
There was a problem hiding this comment.
P2: The local SonarScanner runbook uses the deprecated sonar.login property for authentication. SonarSource replaced this with sonar.token in 2023 and has announced that sonar.login will be removed from SonarQube Cloud on June 11, 2026, after which scans using it will fail to authenticate. Updating the instructions to -Dsonar.token=$SONAR_TOKEN keeps the runbook aligned with current scanner guidance and avoids future breakage.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/sonarqube/config.md, line 45:
<comment>The local SonarScanner runbook uses the deprecated `sonar.login` property for authentication. SonarSource replaced this with `sonar.token` in 2023 and has announced that `sonar.login` will be removed from SonarQube Cloud on June 11, 2026, after which scans using it will fail to authenticate. Updating the instructions to `-Dsonar.token=$SONAR_TOKEN` keeps the runbook aligned with current scanner guidance and avoids future breakage.</comment>
<file context>
@@ -0,0 +1,114 @@
+sonar-scanner \
+ -Dsonar.projectKey=EmiyaKiritsugu3_PWeb_Project \
+ -Dsonar.organization=emiyakiritsugu3 \
+ -Dsonar.login=$SONAR_TOKEN
+```
+
</file context>
| retries: 5 | ||
|
|
||
| app: | ||
| image: node:22-alpine |
There was a problem hiding this comment.
P2: Because the app service bind-mounts the host repository and runs as root, generated files (.next/, node_modules/.prisma/, updated lockfiles, etc.) are created as root on Linux hosts. This causes local permission issues when developers later need to edit or remove those files.
You can avoid this by running the container with the host user's UID/GID, for example by adding user: "${UID:-1000}:${GID:-1000}" to the service and starting Compose with UID=$(id -u) GID=$(id -g) docker compose up. Alternatively, a custom image that creates and switches to a non-root user with matching ownership would also work.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docker-compose.yml, line 25:
<comment>Because the `app` service bind-mounts the host repository and runs as root, generated files (`.next/`, `node_modules/.prisma/`, updated lockfiles, etc.) are created as `root` on Linux hosts. This causes local permission issues when developers later need to edit or remove those files.
You can avoid this by running the container with the host user's UID/GID, for example by adding `user: "${UID:-1000}:${GID:-1000}"` to the service and starting Compose with `UID=$(id -u) GID=$(id -g) docker compose up`. Alternatively, a custom image that creates and switches to a non-root user with matching ownership would also work.</comment>
<file context>
@@ -0,0 +1,44 @@
+ retries: 5
+
+ app:
+ image: node:22-alpine
+ container_name: pweb_app
+ working_dir: /app
</file context>
| db: | ||
| condition: service_healthy | ||
| environment: | ||
| DATABASE_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public |
There was a problem hiding this comment.
P2: The DATABASE_URL and DIRECT_URL connection strings are constructed by directly interpolating POSTGRES_PASSWORD and other fields, which means any special URI characters (@, :, #, ?) in those values will produce an unparseable connection string. For example, a password like p@ss#123 breaks Prisma/libpq URL parsing because # is treated as a URI fragment anchor and ? conflicts with the schema=public query parameter. The database container itself will still initialize correctly because it receives the raw POSTGRES_PASSWORD value, but the app container will fail to connect. Consider allowing developers to supply pre-encoded DATABASE_URL/DIRECT_URL values directly as environment variables, falling back to the composed URL only when they are not explicitly provided.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docker-compose.yml, line 32:
<comment>The `DATABASE_URL` and `DIRECT_URL` connection strings are constructed by directly interpolating `POSTGRES_PASSWORD` and other fields, which means any special URI characters (`@`, `:`, `#`, `?`) in those values will produce an unparseable connection string. For example, a password like `p@ss#123` breaks Prisma/libpq URL parsing because `#` is treated as a URI fragment anchor and `?` conflicts with the `schema=public` query parameter. The database container itself will still initialize correctly because it receives the raw `POSTGRES_PASSWORD` value, but the app container will fail to connect. Consider allowing developers to supply pre-encoded `DATABASE_URL`/`DIRECT_URL` values directly as environment variables, falling back to the composed URL only when they are not explicitly provided.</comment>
<file context>
@@ -0,0 +1,44 @@
+ db:
+ condition: service_healthy
+ environment:
+ DATABASE_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public
+ DIRECT_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public
+ NODE_ENV: ${NODE_ENV:-development}
</file context>
| restart: unless-stopped | ||
| environment: | ||
| POSTGRES_USER: ${POSTGRES_USER:-postgres} | ||
| POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres} |
There was a problem hiding this comment.
P2: GitGuardian flagged this hardcoded default password. While it's a local-dev compose file, the inline fallback postgres triggers secret scanners and could be inadvertently used in non-local environments. Consider requiring credentials from a .env file (with an .env.example documenting the expected keys) or adding a GitGuardian ignore annotation for this file.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docker-compose.yml, line 12:
<comment>GitGuardian flagged this hardcoded default password. While it's a local-dev compose file, the inline fallback `postgres` triggers secret scanners and could be inadvertently used in non-local environments. Consider requiring credentials from a `.env` file (with an `.env.example` documenting the expected keys) or adding a GitGuardian ignore annotation for this file.</comment>
<file context>
@@ -0,0 +1,44 @@
+ restart: unless-stopped
+ environment:
+ POSTGRES_USER: ${POSTGRES_USER:-postgres}
+ POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres}
+ POSTGRES_DB: ${POSTGRES_DB:-pweb}
+ ports:
</file context>
|
|
||
| ## Como registrar | ||
|
|
||
| Após scan (CI job `SonarCloud Scan`): |
There was a problem hiding this comment.
P3: The documentation refers to SonarCloud Scan as a "CI job", but in .github/workflows/ci.yml it is a step inside the test job ("Tests & Coverage"), not a standalone job. This could confuse readers looking for a separate job in the workflow or misidentifying where scan results and artifacts reside. Consider changing "CI job" to "CI step" so the instructions match the actual workflow structure.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/sonarqube/scans.md, line 15:
<comment>The documentation refers to `SonarCloud Scan` as a "CI job", but in `.github/workflows/ci.yml` it is a step inside the `test` job ("Tests & Coverage"), not a standalone job. This could confuse readers looking for a separate job in the workflow or misidentifying where scan results and artifacts reside. Consider changing "CI job" to "CI step" so the instructions match the actual workflow structure.</comment>
<file context>
@@ -0,0 +1,19 @@
+
+## Como registrar
+
+Após scan (CI job `SonarCloud Scan`):
+
+1. Abrir link do dashboard SonarCloud.
</file context>
Suggested change
| Após scan (CI job `SonarCloud Scan`): | |
| Após scan (CI step `SonarCloud Scan`): |
| DIRECT_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public | ||
| NODE_ENV: ${NODE_ENV:-development} | ||
| ports: | ||
| - '${APP_PORT:-3000}:3000' |
There was a problem hiding this comment.
P3: The app service port mapping binds to all host interfaces by default, making the Next.js development server reachable from the entire local network. Since this is a development environment running npm run dev, it may expose debugging endpoints, source maps, or verbose errors beyond localhost. Consider restricting the binding to 127.0.0.1 unless LAN access is intentionally needed: 127.0.0.1:${APP_PORT:-3000}:3000.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docker-compose.yml, line 36:
<comment>The app service port mapping binds to all host interfaces by default, making the Next.js development server reachable from the entire local network. Since this is a development environment running `npm run dev`, it may expose debugging endpoints, source maps, or verbose errors beyond localhost. Consider restricting the binding to `127.0.0.1` unless LAN access is intentionally needed: `127.0.0.1:${APP_PORT:-3000}:3000`.</comment>
<file context>
@@ -0,0 +1,44 @@
+ DIRECT_URL: postgresql://${POSTGRES_USER:-postgres}:${POSTGRES_PASSWORD:-postgres}@db:5432/${POSTGRES_DB:-pweb}?schema=public
+ NODE_ENV: ${NODE_ENV:-development}
+ ports:
+ - '${APP_PORT:-3000}:3000'
+ volumes:
+ - .:/app
</file context>
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="docs/sonarqube/scans.md">
<violation number="1" location="docs/sonarqube/scans.md:15">
P3: The documentation refers to `SonarCloud Scan` as a "CI job", but in `.github/workflows/ci.yml` it is a step inside the `test` job ("Tests & Coverage"), not a standalone job. This could confuse readers looking for a separate job in the workflow or misidentifying where scan results and artifacts reside. Consider changing "CI job" to "CI step" so the instructions match the actual workflow structure.</violation>
</file>
<file name="docs/CURRENT-STATE.md">
<violation number="1" location="docs/CURRENT-STATE.md:23">
P2: The date `2026-07-10` is a Friday, not a Thursday. The cron schedule `3 9 * * 1,4` fires on Mondays (1) and Thursdays (4), so a Friday execution will never occur. The next Thursday after 2026-07-06 is `2026-07-09`.</violation>
</file>
<file name="sonar-project.properties">
<violation number="1" location="sonar-project.properties:16">
P1: Using `sonar.exclusions` to exclude `src/components/ui/**` removes these files from **all** SonarCloud analysis — not just coverage, but also bug detection, vulnerability scanning, code smells, duplication checks, and maintainability metrics. Since the PR intent is only to improve branch coverage numbers (described as excluding lib wrappers), using `sonar.coverage.exclusions` instead limits the exclusion to coverage while preserving quality analysis on those 74 component files.</violation>
</file>
<file name="docs/sonarqube/config.md">
<violation number="1" location="docs/sonarqube/config.md:24">
P2: The documented `sonar.test.inclusions` values use `ts(x)` shorthand, but SonarScanner properties use simple wildcard patterns (`*`, `**`, `?`) where parenthetical groups are not supported. If someone copies these documented globs into `sonar-project.properties`, `.test.ts` and `.test.tsx` files won't be matched correctly, which can break test indexing and coverage classification. It would be good to align the documentation with the actual property file syntax — either by listing the comma-separated patterns explicitly (as done in `sonar-project.properties`) or by using `*.test.ts*` which the wildcard syntax does support.</violation>
<violation number="2" location="docs/sonarqube/config.md:45">
P2: The local SonarScanner runbook uses the deprecated `sonar.login` property for authentication. SonarSource replaced this with `sonar.token` in 2023 and has announced that `sonar.login` will be removed from SonarQube Cloud on June 11, 2026, after which scans using it will fail to authenticate. Updating the instructions to `-Dsonar.token=$SONAR_TOKEN` keeps the runbook aligned with current scanner guidance and avoids future breakage.</violation>
<violation number="3" location="docs/sonarqube/config.md:50">
P2: The CI documentation describes a `sonar` job that does not exist and a shell-based scan step that is not what the workflow actually uses. In `.github/workflows/ci.yml`, the SonarCloud scan is a step inside the `test` job using `SonarSource/sonarqube-scan-action`, not a separate `sonar` job running `sonar-scanner`. This mismatch will mislead anyone trying to debug or update the scan configuration. Updating section 5 to match the real `test` job and action-based step would keep the runbook accurate.</violation>
<violation number="4" location="docs/sonarqube/config.md:84">
P2: The metrics table reports `0` current code smells, but the next paragraph documents `16 smells` as known pending items in `docs/TECHNICAL-DEBT.md`. Even if those 16 are marked as false positives, the proximity creates a contradiction for readers: the table suggests zero total smells while the text confirms 16 documented ones exist. To avoid misrepresenting the project's quality baseline, consider clarifying the `Atual` value as `0 (unresolved)` or `0 ativos`, and add a brief note in the same row or immediately after explaining that 16 additional smells are documented as false positives and do not count toward the current unresolved total.</violation>
</file>
<file name="docker-compose.yml">
<violation number="1" location="docker-compose.yml:8">
P2: Hard-coded `container_name` values on both services prevent Docker Compose from namespacing containers by project. This blocks running multiple concurrent Compose instances (e.g., different branches, CI jobs, or shared dev hosts) and breaks Compose scaling behavior. Since there are no other references to `pweb_db` or `pweb_app` elsewhere in the repo, these explicit names aren't required for cross-referencing. Removing `container_name` from both services lets Compose generate safe, unique names automatically.</violation>
<violation number="2" location="docker-compose.yml:12">
P2: GitGuardian flagged this hardcoded default password. While it's a local-dev compose file, the inline fallback `postgres` triggers secret scanners and could be inadvertently used in non-local environments. Consider requiring credentials from a `.env` file (with an `.env.example` documenting the expected keys) or adding a GitGuardian ignore annotation for this file.</violation>
<violation number="3" location="docker-compose.yml:15">
P1: The database service is published on the host port without an explicit bind address and falls back to the well-known default password `postgres`. Docker Compose port mappings without a bind address listen on all interfaces (`0.0.0.0`), so if this stack is run on a VM or any host with a public network interface, PostgreSQL becomes externally reachable with a default credential. Consider restricting the port binding to localhost: `127.0.0.1:${POSTGRES_PORT:-5432}:5432`. It is also worth evaluating whether a hard-coded default superuser password should be provided at all.</violation>
<violation number="4" location="docker-compose.yml:17">
P2: The `pweb_pgdata` volume persists the Postgres data directory, so `POSTGRES_USER`, `POSTGRES_PASSWORD`, and `POSTGRES_DB` are only applied on the very first initialization. If anyone changes those environment values later, the app’s `DATABASE_URL` will immediately reference new credentials that don’t exist in the persisted database, causing confusing connection and migration failures. Consider adding a comment warning that changes to these variables require recreating the volume (`docker volume rm pweb_pgdata`).</violation>
<violation number="5" location="docker-compose.yml:25">
P2: Because the `app` service bind-mounts the host repository and runs as root, generated files (`.next/`, `node_modules/.prisma/`, updated lockfiles, etc.) are created as `root` on Linux hosts. This causes local permission issues when developers later need to edit or remove those files.
You can avoid this by running the container with the host user's UID/GID, for example by adding `user: "${UID:-1000}:${GID:-1000}"` to the service and starting Compose with `UID=$(id -u) GID=$(id -g) docker compose up`. Alternatively, a custom image that creates and switches to a non-root user with matching ownership would also work.</violation>
<violation number="6" location="docker-compose.yml:32">
P2: The `DATABASE_URL` and `DIRECT_URL` connection strings are constructed by directly interpolating `POSTGRES_PASSWORD` and other fields, which means any special URI characters (`@`, `:`, `#`, `?`) in those values will produce an unparseable connection string. For example, a password like `p@ss#123` breaks Prisma/libpq URL parsing because `#` is treated as a URI fragment anchor and `?` conflicts with the `schema=public` query parameter. The database container itself will still initialize correctly because it receives the raw `POSTGRES_PASSWORD` value, but the app container will fail to connect. Consider allowing developers to supply pre-encoded `DATABASE_URL`/`DIRECT_URL` values directly as environment variables, falling back to the composed URL only when they are not explicitly provided.</violation>
<violation number="7" location="docker-compose.yml:34">
P1: The container is explicitly a development environment (runs `npm run dev`, Prisma migrations, and seeding), yet it allows the host to override `NODE_ENV`. If an external shell sets `NODE_ENV=production`, `npm install` will skip devDependencies by default, and both `prisma` and `tsx` (which are in `devDependencies`) won't be installed on disk. This will cause `npx prisma migrate deploy` and the seed step to fail immediately on container start. Since this compose file is only for local development, consider hardcoding `NODE_ENV: development` instead of allowing a host override.</violation>
<violation number="8" location="docker-compose.yml:36">
P3: The app service port mapping binds to all host interfaces by default, making the Next.js development server reachable from the entire local network. Since this is a development environment running `npm run dev`, it may expose debugging endpoints, source maps, or verbose errors beyond localhost. Consider restricting the binding to `127.0.0.1` unless LAN access is intentionally needed: `127.0.0.1:${APP_PORT:-3000}:3000`.</violation>
</file>
<file name="docs/relatorio-testes.md">
<violation number="1" location="docs/relatorio-testes.md:50">
P2: The test report no longer documents the pending bugs mentioned in the PR description. The previous version included a 'Bugs Pendentes' section listing open issues such as #160 (SonarQube smells) and #122 (ESLint upstream block), but the rewrite removed this section entirely while the PR description claims the report still documents them alongside corrected bugs #188–#190. To keep the report complete, consider restoring a section for known unresolved/pending issues so the document matches its stated scope.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| @@ -1,305 +1,118 @@ | |||
| # Relatório de Testes — Iteração 3 (P4) | |||
| # Relatório de Testes — Iteração 4 (P5) | |||
There was a problem hiding this comment.
P2: The test report no longer documents the pending bugs mentioned in the PR description. The previous version included a 'Bugs Pendentes' section listing open issues such as #160 (SonarQube smells) and #122 (ESLint upstream block), but the rewrite removed this section entirely while the PR description claims the report still documents them alongside corrected bugs #188–#190. To keep the report complete, consider restoring a section for known unresolved/pending issues so the document matches its stated scope.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/relatorio-testes.md, line 50:
<comment>The test report no longer documents the pending bugs mentioned in the PR description. The previous version included a 'Bugs Pendentes' section listing open issues such as #160 (SonarQube smells) and #122 (ESLint upstream block), but the rewrite removed this section entirely while the PR description claims the report still documents them alongside corrected bugs #188–#190. To keep the report complete, consider restoring a section for known unresolved/pending issues so the document matches its stated scope.</comment>
<file context>
@@ -8,206 +8,74 @@
+---
-**Testes:** 2 arquivos (page, client)
+## 3. Tabela 2 — Providências
-### US12 — Feedback IA Pós-Treino
</file context>
T01: sonar-project.properties +src/lib/actions/** em sonar.exclusions (alinha vitest + doc-deploy). T02: doc-deploy §3 lista 10 exclusões de cobertura (não 2), sincroniza com vitest.config.ts. T03: sonarqube/config.md §6 cron 3 9 * * 1,4 alinhado com ci.yml. T04: doc-deploy §6 + §8 documentam release RC-v1.0 iteração 4, tag v1.0.0, GitHub Release, ADF coverage table. T06: sonarqube/scans.md placeholder 2ª exec 2026-07-10 PENDING via cron. T07: CURRENT-STATE.md seção Remediação P5 lista T01-T09. Auditoria adversarial (3 Explore + 1 code-reviewer) pré-merge PR #191. Co-Authored-By: Claude <noreply@anthropic.com>
Contributor
|
ECC bundle files are already tracked in this repository. Skipping generation of another bundle PR. |
|
There was a problem hiding this comment.
3 issues found across 5 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="docs/doc-deploy.md">
<violation number="1" location="docs/doc-deploy.md:87">
P2: The coverage exclusions section claims **10 patterns** but `vitest.config.ts` only defines 9, and the listed bullets enumerate 9 in total. In a quality-gate document, misrepresenting the number of excluded coverage patterns can mislead reviewers or auditors about what is actually excluded. Updating the count from **10** to **9** keeps the doc aligned with the real config.</violation>
<violation number="2" location="docs/doc-deploy.md:105">
P2: The manual SonarScanner example uses `-Dsonar.login`, which is officially deprecated by SonarSource in favor of `-Dsonar.token`. Developers following these instructions will see deprecation warnings, and the docs are out of sync with the project's own CI workflow (which already uses `SONAR_TOKEN` with the official `sonarqube-scan-action`). Consider updating the example to use `-Dsonar.token=$SONAR_TOKEN` to match current tooling and the CI setup.</violation>
<violation number="3" location="docs/doc-deploy.md:121">
P1: The `SUPABASE_SERVICE_ROLE_KEY` is a highly privileged credential that bypasses Row Level Security. The deployment guide lists it as a required Vercel environment variable but does not mention scoping it to Production-only or warning that Preview deployments (created for every PR) will expose it to server-side code. Consider adding guidance to restrict this key to the Production environment in Vercel, or at minimum include a security note about its privileges in preview/staging contexts.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| 3. Build: `npm run build`. | ||
| 4. Variáveis de ambiente (Vercel → Settings → Environment Variables): | ||
| - `DATABASE_URL`, `DIRECT_URL` (Vercel Postgres) | ||
| - `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY`, `SUPABASE_SERVICE_ROLE_KEY` |
There was a problem hiding this comment.
P1: The SUPABASE_SERVICE_ROLE_KEY is a highly privileged credential that bypasses Row Level Security. The deployment guide lists it as a required Vercel environment variable but does not mention scoping it to Production-only or warning that Preview deployments (created for every PR) will expose it to server-side code. Consider adding guidance to restrict this key to the Production environment in Vercel, or at minimum include a security note about its privileges in preview/staging contexts.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/doc-deploy.md, line 121:
<comment>The `SUPABASE_SERVICE_ROLE_KEY` is a highly privileged credential that bypasses Row Level Security. The deployment guide lists it as a required Vercel environment variable but does not mention scoping it to Production-only or warning that Preview deployments (created for every PR) will expose it to server-side code. Consider adding guidance to restrict this key to the Production environment in Vercel, or at minimum include a security note about its privileges in preview/staging contexts.</comment>
<file context>
@@ -0,0 +1,195 @@
+3. Build: `npm run build`.
+4. Variáveis de ambiente (Vercel → Settings → Environment Variables):
+ - `DATABASE_URL`, `DIRECT_URL` (Vercel Postgres)
+ - `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY`, `SUPABASE_SERVICE_ROLE_KEY`
+ - `GEMINI_API_KEY` / `GOOGLE_GENAI_API_KEY`
+ - `NEXT_PUBLIC_APP_URL`, `SENTRY_DSN`, `SENTRY_AUTH_TOKEN`
</file context>
| ### Cobertura | ||
| - Reporter: Vitest v8 (`coverage/lcov.info`) | ||
| - Threshold: branch ≥ 80% (atual: **84.53%**) | ||
| - Exclusões (10 patterns, alinhadas com `vitest.config.ts`): |
There was a problem hiding this comment.
P2: The coverage exclusions section claims 10 patterns but vitest.config.ts only defines 9, and the listed bullets enumerate 9 in total. In a quality-gate document, misrepresenting the number of excluded coverage patterns can mislead reviewers or auditors about what is actually excluded. Updating the count from 10 to 9 keeps the doc aligned with the real config.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/doc-deploy.md, line 87:
<comment>The coverage exclusions section claims **10 patterns** but `vitest.config.ts` only defines 9, and the listed bullets enumerate 9 in total. In a quality-gate document, misrepresenting the number of excluded coverage patterns can mislead reviewers or auditors about what is actually excluded. Updating the count from **10** to **9** keeps the doc aligned with the real config.</comment>
<file context>
@@ -0,0 +1,195 @@
+### Cobertura
+- Reporter: Vitest v8 (`coverage/lcov.info`)
+- Threshold: branch ≥ 80% (atual: **84.53%**)
+- Exclusões (10 patterns, alinhadas com `vitest.config.ts`):
+ - `src/lib/actions/**` (server actions, E2E Prisma/Supabase)
+ - `src/components/ui/**` (shadcn/Radix wrappers, E2E)
</file context>
Suggested change
| - Exclusões (10 patterns, alinhadas com `vitest.config.ts`): | |
| - Exclusões (9 patterns, alinhadas com `vitest.config.ts`): |
| ```bash | ||
| sonar-scanner \ | ||
| -Dsonar.projectKey=PWeb_Project \ | ||
| -Dsonar.login=$SONAR_TOKEN |
There was a problem hiding this comment.
P2: The manual SonarScanner example uses -Dsonar.login, which is officially deprecated by SonarSource in favor of -Dsonar.token. Developers following these instructions will see deprecation warnings, and the docs are out of sync with the project's own CI workflow (which already uses SONAR_TOKEN with the official sonarqube-scan-action). Consider updating the example to use -Dsonar.token=$SONAR_TOKEN to match current tooling and the CI setup.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/doc-deploy.md, line 105:
<comment>The manual SonarScanner example uses `-Dsonar.login`, which is officially deprecated by SonarSource in favor of `-Dsonar.token`. Developers following these instructions will see deprecation warnings, and the docs are out of sync with the project's own CI workflow (which already uses `SONAR_TOKEN` with the official `sonarqube-scan-action`). Consider updating the example to use `-Dsonar.token=$SONAR_TOKEN` to match current tooling and the CI setup.</comment>
<file context>
@@ -0,0 +1,195 @@
+```bash
+sonar-scanner \
+ -Dsonar.projectKey=PWeb_Project \
+ -Dsonar.login=$SONAR_TOKEN
+```
+
</file context>
EmiyaKiritsugu3
added a commit
that referenced
this pull request
Jul 7, 2026
* fix(p5): remedia reviews PR #191 (security + docs) R01 docker-compose: rm container_name, bind 127.0.0.1, NODE_ENV hardcode, POSTGRES_PASSWORD required R02 sonar coverage.exclusions UI (mantem analise qualidade) R03 doc-deploy SUPABASE_SERVICE_ROLE_KEY bypass RLS warning R04 date 2026-07-10 to 09 (4 loc: CURRENT-STATE, scans, relatorio) R05 sonar.login to sonar.token (config.md, doc-deploy) R06 doc-deploy 10 to 9 patterns (vitest 9 entries) R07 config.md job sonar to step sonarqube-scan-action (espelha ci.yml) R08 config.md test.inclusions 4 globs exactos R09 config.md smells 0 ativos (16 FP TECHNICAL-DEBT) R10 relatorio restore Bugs Pendentes + GitGuardian FP + reword Conclusao R11 docker-compose comments volume pweb_pgdata + app root R12 doc-deploy POSTGRES_PASSWORD chars especiais quebram DATABASE_URL Gates: lint typecheck test 1137/1137 format green * fix(p5): bump sonarqube-scan-action v4.2.2 EOL to v8.2.0 (cubic P1) ci.yml L106 SHA 689fb39 -> 71388167 (v8.2.0). v4.2.2 EOL + security vuln runtime warning (cubic P1 PR #192). config.md S5 doc alinhado. Env GITHUB_TOKEN/SONAR_TOKEN unchanged. --------- Co-authored-by: Emiya Kiritsugu <emiyakiritsugu3@users.noreply.github.com>
EmiyaKiritsugu3
added a commit
that referenced
this pull request
Jul 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tarefa P5 (Eng Software II, iteracao 4): Integracao Continua, Implantacao e Qualidade.
Tarefa
https://github.com/tacianosilva/eng-software-2/blob/main/tarefas/projetos/P5-tarefa5.md
Entregas P5
1. Cobertura de codigo (P5 secao 4)
Branch coverage 79.65% -> 84.53% (alvo 80%).
src/components/ui/**(shadcn/Radix wrappers — codigo de lib, nao negocio) do coverage vitest + SonarQube.2. Docker (P5 secao 5)
docker-compose.yml: postgres:16-alpine + node:22-alpine (dev com migrate/seed auto). Healthcheck + volumes persistente.3. Docs deploy + sonarqube (P5 secao 4-5)
docs/doc-deploy.md: compose, CI gates, SonarQube, Vercel deploy, SemVer, Conventional Commits, AcademicDevFlow.docs/sonarqube/config.md: SonarCloud config, execucao, cadencia 2x/semana, quality gate, false positives.docs/sonarqube/scans.md: registro 1a execucao (2026-07-06, 84.53%, PASS).4. CI cron (P5 secao 4)
.github/workflows/ci.yml:schedule: cron '3 9 * * 1,4'+workflow_dispatch(SonarQube 2x/semana seg+qui).5. Relatorio de testes (P5 secao 3)
docs/relatorio-testes.mditeracao 3 -> 4:6. Issues de bugs (P5 secao 3)
Criadas + fechadas: #188 (coverage), #189 (docker), #190 (docs).
Gates
Diff
7 files changed, +250/-24
Notas
Refs: tarefa P5
Co-Authored-By: Claude noreply@anthropic.com
Summary by cubic
Sets up CI quality gates and local Docker dev for Iteration 4 (P5): scheduled SonarCloud scans,
docker-compose.yml(Postgres + Node), and coverage exclusions to reach 84.53% branch coverage (≥80%). Aligns Sonar/docs with cron, addssrc/lib/actions/**to exclusions, documents the RC‑v1.0 release, and updates the P5 test report anddocs/CURRENT-STATE.md.New Features
.github/workflows/ci.ymlruns SonarCloud 2x/week (3 9 * * 1,4) and supportsworkflow_dispatch.docker-compose.ymlwith Postgres 16‑alpine + Node 22‑alpine (migrate/seed, healthcheck, persistent volumes).src/components/ui/**andsrc/lib/actions/**in Vitest and Sonar; branch coverage 79.65% → 84.53%; updates tovitest.config.tsandsonar-project.properties.docs/doc-deploy.md(now lists 10 coverage exclusions, RC‑v1.0 with tagv1.0.0and ADF table),docs/sonarqube/config.md(cron aligned),docs/sonarqube/scans.md(1st scan logged + 2nd scheduled), updateddocs/relatorio-testes.md(US13 A1/A2/A3) anddocs/CURRENT-STATE.md(remediation notes).Migration
docker compose up -d; app onlocalhost:3000, DB onlocalhost:5432.SONAR_TOKENto GitHub Actions secrets for SonarCloud scans.Written for commit cccf753. Summary will update on new commits.
Summary by CodeRabbit
New Features
Documentation
Bug Fixes