📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,104 @@
|
||||
# Pre-release Review Checklist
|
||||
|
||||
Use this checklist to find production release risks from a PR or git diff. Report only categories
|
||||
with confirmed problems or plausible risks that need confirmation.
|
||||
|
||||
## Database and data changes
|
||||
|
||||
- Schema or ORM model changes without corresponding migration files.
|
||||
- New columns, enums, constraints, indexes, partitions, triggers, functions, or extensions that need
|
||||
deploy-time DDL.
|
||||
- Destructive migrations, column renames, type changes, constraint tightening, or data rewrites
|
||||
without backward-compatible rollout or rollback notes.
|
||||
- New required data without seed, backfill, admin setup, or one-time SQL.
|
||||
- Index changes that may lock large tables or need concurrent/online creation.
|
||||
- Query changes that depend on data shape not guaranteed in production.
|
||||
- Migration files present but not referenced by the deploy system or migration runner.
|
||||
|
||||
## Environment and configuration
|
||||
|
||||
- New env var, config key, feature flag, secret name, or runtime option without example/default,
|
||||
deployment platform update, or CI/CD secret update.
|
||||
- Config key rename/removal that may break existing production variables.
|
||||
- Code that reads production-only values without validation or safe failure behavior.
|
||||
- Feature flags without documented default state, owner, rollout plan, or kill switch.
|
||||
- Docker, Kubernetes, Helm, Terraform, Railway, Vercel, GitHub Actions, or similar deploy config
|
||||
changes that require manual environment changes.
|
||||
|
||||
## Security and sensitive material
|
||||
|
||||
- Private keys, tokens, passwords, certificates, cookies, `.pem`, `.key`, `.p12`, `.env`, service
|
||||
account JSON, or cloud credentials added to the diff.
|
||||
- Logs, errors, analytics, webhooks, or traces that may expose PII, tokens, session IDs, or payment
|
||||
data.
|
||||
- Debug endpoints, admin bypasses, permissive CORS, disabled auth, relaxed TLS, or temporary
|
||||
development flags.
|
||||
- IAM, ACL, bucket policy, database role, queue permission, webhook signature, or API key scope
|
||||
changes without release coordination.
|
||||
- Dependency or container changes with known security-sensitive behavior, native binaries, or
|
||||
postinstall scripts.
|
||||
|
||||
## Cache, CDN, and derived state
|
||||
|
||||
- Redis key format, namespace, TTL, serialization, or value shape changes without invalidation or
|
||||
backward compatibility.
|
||||
- Code that assumes warmed cache, precomputed data, materialized views, search indexes, or derived
|
||||
tables exist.
|
||||
- CDN/static asset paths, cache headers, ETags, versioning, or purge requirements changed.
|
||||
- Rollout can serve mixed old/new cache values during a partial deploy.
|
||||
- Feature removal leaves stale cache keys that can revive old behavior.
|
||||
|
||||
## Queues, events, and schedulers
|
||||
|
||||
- New topic, queue, routing key, exchange, subscription, event type, cron job, or scheduled worker.
|
||||
- Producer and consumer contract changes without compatible deployment order.
|
||||
- Missing DLQ, retry policy, idempotency, dedupe key, or poison-message handling.
|
||||
- Worker concurrency, timeout, rate limit, or backpressure changes that may overload dependencies.
|
||||
- Event payload shape changes without versioning or old-consumer compatibility.
|
||||
|
||||
## External services and assets
|
||||
|
||||
- New object storage, CDN, S3, OSS, GCS, or static asset references without upload or permissions
|
||||
confirmation.
|
||||
- Email, SMS, push, PDF, image, translation, or notification templates changed without production
|
||||
material update.
|
||||
- Webhook URL, callback domain, redirect URI, CORS origin, OAuth app, payment provider, or third
|
||||
party whitelist changes.
|
||||
- New cloud resource, bucket, DNS record, certificate, API product, SaaS setting, or quota need.
|
||||
- Frontend build assets depend on backend routes or config that are not deployed yet.
|
||||
|
||||
## Service dependencies and deployment order
|
||||
|
||||
- API contract changes affecting web, mobile, workers, indexers, schedulers, or third parties.
|
||||
- Database migration must run before or after specific service versions.
|
||||
- Worker should be paused, drained, or deployed after producers.
|
||||
- Read/write compatibility risks during rolling deploys.
|
||||
- New background jobs, queues, or cache consumers need infrastructure before application deploy.
|
||||
- Rollback would be unsafe because schema, data, cache, or queue payloads are not backward
|
||||
compatible.
|
||||
|
||||
## CI/CD and release automation
|
||||
|
||||
- Workflow, Dockerfile, build script, deploy script, package manager, lockfile, or artifact path
|
||||
changed.
|
||||
- Required build-time env var, secret, binary, system package, or runtime version changed.
|
||||
- Tag/release workflow depends on files or outputs not updated in the diff.
|
||||
- Migration, seed, asset upload, or cache purge step is manual but not documented.
|
||||
- Tests, linters, or type checks disabled or narrowed for release-critical code.
|
||||
|
||||
## Observability and operations
|
||||
|
||||
- New critical path without logs, metrics, traces, health checks, dashboards, or alerts.
|
||||
- Error handling changed without actionable logs or rollback signal.
|
||||
- Runbook, release checklist, incident response, or support notes missing for operational changes.
|
||||
- Kill switch, feature flag, or emergency disable path absent for risky functionality.
|
||||
- SLO, rate limit, quota, or capacity implication not addressed.
|
||||
|
||||
## Reportable "unable to verify" cases
|
||||
|
||||
- Remote PR diff cannot be fetched.
|
||||
- Release tag cannot be found and the audit fell back to recent commits.
|
||||
- Deployment platform config, production secrets, cloud buckets, queues, or external SaaS settings
|
||||
are not accessible from the local repository.
|
||||
- Owner cannot be inferred from blame/log evidence.
|
||||
- Diff is too large to inspect fully within the available time or tool limits.
|
||||
@@ -0,0 +1,91 @@
|
||||
# Pre-release Review Report Template
|
||||
|
||||
Use this template for the final report. Translate headings to the user's language if useful, but
|
||||
keep the same sections, priority labels, conclusion values, and finding fields.
|
||||
|
||||
## Priority definitions
|
||||
|
||||
- `P0` - Block release. A production deploy is likely to fail, corrupt data, expose secrets, break
|
||||
compatibility, or require a missing manual action.
|
||||
- `P1` - High risk, must confirm before release. Evidence suggests a production dependency,
|
||||
migration, config, cache, queue, asset, or service-order risk.
|
||||
- `P2` - Medium risk or ambiguous gap. Not clearly blocking, but should be checked before release
|
||||
because the diff introduces uncertainty.
|
||||
- `P3` - Low-risk note. Do not include P3 in the main report unless the user asks for a complete
|
||||
audit log.
|
||||
|
||||
## Conclusion values
|
||||
|
||||
- `BLOCKED` - At least one P0 finding exists.
|
||||
- `NEEDS_CONFIRMATION` - No P0 was found, but one or more P1/P2 items need confirmation.
|
||||
- `NO_BLOCKER_FOUND` - No P0-P2 finding or release confirmation item was found from available
|
||||
evidence. Neutral verification limits may still be listed separately.
|
||||
|
||||
## Findings versus Unable To Verify
|
||||
|
||||
- Put diff-linked production risks in `Findings`. Examples: a new env var whose production value
|
||||
cannot be verified, a schema change with unclear migration execution, or a new queue whose
|
||||
infrastructure is not confirmed.
|
||||
- Any P1 or P2 finding means the conclusion is `NEEDS_CONFIRMATION` unless a P0 makes it `BLOCKED`.
|
||||
- Put only neutral tool or access limits in `Unable To Verify`. Examples: remote PR access is
|
||||
unavailable, deployment platform access is unavailable, or owner inference failed without a
|
||||
specific release-critical change.
|
||||
- If an access/tool limitation prevents confirmation of a release-critical diff change, promote it
|
||||
to a P1/P2 finding instead of leaving it only in `Unable To Verify`.
|
||||
|
||||
## Owner inference
|
||||
|
||||
- Prefer `git blame` on changed lines for the file and line that caused the finding.
|
||||
- If blame is unavailable or misleading, use `git log --format="%h %an %s" -- <path>`.
|
||||
- If several commits contributed to the same release risk, list all relevant author names.
|
||||
- Mark owners as "inferred" and do not expose email addresses.
|
||||
- If no owner can be inferred, write `Unknown (not inferable from local git evidence)`.
|
||||
|
||||
## Secret redaction
|
||||
|
||||
- Never print secret values, even partially, unless the value is already a harmless placeholder such
|
||||
as `example`, `changeme`, or `REDACTED`.
|
||||
- Report secrets as: path, line, variable/key name, type, and redacted hint.
|
||||
- Example: `config/prod.env:12` - `PAYMENT_API_KEY`, suspected API key, value redacted.
|
||||
- Do not paste PEM blocks, JWTs, cookies, session IDs, private keys, passwords, certificates, or
|
||||
cloud credentials into the report.
|
||||
|
||||
## Final report shape
|
||||
|
||||
```markdown
|
||||
# Production Release Readiness Review
|
||||
|
||||
## Scope
|
||||
- Range: <base>..<head> | PR <number> | latest 5 commits fallback
|
||||
- Current branch: <branch>
|
||||
- Head commit: <hash>
|
||||
- Compared from: <tag/hash/pr-base>
|
||||
- Commit count: <count>
|
||||
- Dirty worktree: <yes/no and short note>
|
||||
- Commands used: <short list of read-only commands>
|
||||
|
||||
## Conclusion
|
||||
`BLOCKED` | `NEEDS_CONFIRMATION` | `NO_BLOCKER_FOUND`
|
||||
|
||||
## Findings
|
||||
| Priority | Module | Finding | Evidence | Inferred owner | Risk | Recommended action |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| P0/P1/P2 | <area/service> | <short issue> | <file:line or commit/range> | <name(s) or unknown> | <why it matters> | <release action> |
|
||||
|
||||
## Deployment Order / Release Actions
|
||||
- <Only include when relevant. State service order, migrations, queue/cache/resource actions, and compatibility constraints.>
|
||||
|
||||
## Unable To Verify
|
||||
- <Tooling, auth, remote, production-config, or repository limits that prevent confirmation.>
|
||||
```
|
||||
|
||||
## Finding writing rules
|
||||
|
||||
- Keep each finding actionable and short.
|
||||
- Include only P0-P2 or explicit confirmation risks.
|
||||
- Do not include clean categories like "database OK" or "security OK".
|
||||
- Use evidence-driven wording: "schema changed but no migration file changed" is better than
|
||||
"maybe migration missing".
|
||||
- If risk is ambiguous, say exactly what must be confirmed before release.
|
||||
- If no findings exist, omit the `Findings` table and write:
|
||||
`No P0-P2 release blockers or confirmation items were found from the available repository evidence.`
|
||||
Reference in New Issue
Block a user