fix(deploy): trigger workflow on all data/sql/** changes, not only .sql #320
No reviewers
Labels
No labels
admin
analytics
auth
automation
bug
business
chore
ci
compliance
data
data-moat
docs
duplicate
dx
enhancement
Fable 5 ревью
feedback/max
generative
GG-форсайт
needs-discussion
needs-human
observability
pause-bots
performance
priority/p0
priority/p1
priority/p2
priority/p3
scope/backend
scope/db
scope/devops
scope/frontend
scope/qa
scrapers
security
site-finder
stage/1
stage/2
status/blocked
status/done
status/needs-analysis
status/needs-fix
status/qa
status/ready
status/review
status/wip
tech-debt
tradein
ux
week ревью 1
wontfix
вторичка
ИРД
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lekss361/gendesign#320
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "fix/deploy-paths-data-sql-py"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Bug
PR #318 (
fix(objective parser): wrap bytes-iter in file-like reader for ijson) merged какbb9a003в 17:52:55Z — но deploy.yml workflow НЕ запустился.Подтверждение: Forgejo Actions list — последний run #109 на
3978aa5(TI-2 PDF), нет run дляbb9a003. Worker контейнер всё ещё на коде389e141(PR #315 streaming с brokenijson.items(stream, prefix)без_IterBytesReader).Glitchtip BACKEND-1K (release=
3978aa5, count=4, lastSeen 17:54:44Z) —ValueError: too many values to unpack (expected 3, got 65536)повторяется на КАЖДОМ live trigger.Root cause
.forgejo/workflows/deploy.yml:16top-level path filter:PR #318 изменил только
data/sql/70_parse_objective_raw.py(Python parser, исторически лежит в data/sql/). Top-level фильтрdata/sql/*.sqlне сматчился → workflow skip → deploy не выполнился.Mismatch: внутренний
dorny/paths-filterна строке 47 уже ловит все changes в data/sql/:Но trigger filter ограничен
.sql.Fix
Одна строка:
data/sql/**glob ловит все файлы в этой папке (SQL + Python parsers + etc).Cascade после merge
.forgejo/workflows/deploy.yml→ workflow стартанётgit reset --hard origin/main→ подтянет включаяbb9a003(ijson fix)--force-recreate→ новый код с_IterBytesReader/admin/scrape/objective/sync-our→lots > 0(ijson корректно стримит)Acceptance
objective_lots.raw_id IS NOT NULLcount растётRisk
Минимальный — однострочное расширение path filter pattern. Сам этот PR изменяет
.forgejo/workflows/deploy.yml, что и так в trigger filter → workflow ЗАПУСТИТСЯ корректно на merge.Deep Code Review — verdict APPROVE
Summary
.forgejo/workflows/deploy.yml)Diff verification
Diff confirmed via
get_pr_diff— exactly one line in.forgejo/workflows/deploy.yml:16, nothing else snuck in (additions:1, deletions:1, changed_files:1).Checks
Glob syntax —
**inpaths:IS supported by Forgejo Actions (Gitea-compatible, mirrors GitHub Actions semantics).data/sql/**matches any file at any depth underdata/sql/. Valid.Internal
dorny/paths-filterconsistency —.forgejo/workflows/deploy.yml:43already uses'data/sql/**'in thebackend:filter. Top-level filter now matches internal — no more mismatch where workflow triggers but internal filter says "no backend changes" or vice versa.Cascade reasoning verified — this PR modifies
.forgejo/workflows/deploy.ymlwhich is itself in the trigger paths filter (line 15) → its own merge fires the workflow →git fetch origin main && git reset --hard origin/main(line 178-179) pulls inbb9a003(ijson_IterBytesReaderfix from PR #318) →docker compose ... up -d --force-recreate --no-deps backend worker beat(line 249-250) recreates worker with new code. Self-healing cascade works.No unintended side effects — listed
data/sql/contents: only.sqlmigration files +.pyparsers/loaders (11_load_domrf.py,70_parse_objective_raw.py, etc.) +02_load_all_quarters.sh+decode_to_file.py/upload_server.pyutilities +__pycache__. All of these legitimately affect backend behavior — should trigger deploy. No README/docs/test-fixtures that would cause noise.__pycache__is gitignored anyway. Clean.SQL apply loop (line 223:
for sql_file in $(ls -1 data/sql/*.sql ...)) — unchanged, still correctly filters to.sqlonly on the deploy side. So.pyfiles indata/sql/trigger the build/deploy but are NOT mistakenly fed topsql. Boundary preserved.Cross-file impact
.forgejo/workflows/deploy.yml:43internal filter already aligned — no other files need to change..github/workflows/deploy.ymldivergence concern (Forgejo migration 2026-05-16 made Forgejo the source of truth).Risk
389e141worker code, Glitchtip errors live).Merging.