mirror of
https://github.com/LearningCircuit/local-deep-research.git
synced 2026-06-15 19:46:56 +03:00
0aee7f78f4
* ci(labels): add test:ui-full-shards label + wrapper workflow Adds a new opt-in label that triggers the full 14-shard UI test matrix (jobs ui-tests in docker-tests.yml). The matrix is otherwise gated on strict-mode=true and only runs at release time, so PR authors had no way to exercise it on demand without manually dispatching the workflow. Implementation: - New .github/workflows/ui-full-shards.yml — minimal wrapper that triggers on `pull_request: types: [labeled]` and calls docker-tests.yml via workflow_call with strict-mode=true, gated on the label name. - labels.yml entry for test:ui-full-shards with an AI-reviewer-friendly imperative description in the same style as benchmark-needed. - Live GitHub label created out-of-band (color matches test:puppeteer). Trade-off acknowledged in the workflow's top comment: strict-mode runs the FULL docker-tests job graph (image build + pytest + infra + ui), re-doing work that the normal PR docker-tests already ran. Acceptable cost for a deliberate label-driven trigger; a cleaner refactor (extract ui-tests into a standalone reusable workflow) is a bigger PR and was explicitly deferred. * ci(ui-full-shards): add workflow_dispatch + accept manual triggers The label trigger (`pull_request: types: [labeled]`) cannot fire from the PR that introduces a workflow file — GitHub Actions only honors the trigger once the workflow definition lands on the base branch. That made it impossible to smoke-test the wiring on PR #4067 itself. Add `workflow_dispatch` as a fallback so: - A maintainer can manually fire the 14-shard run from the Actions UI without having to label a PR. - We can smoke-test the wrapper immediately after merge by dispatching it against any branch, instead of waiting for a real label-triggered PR run. Update the job's `if:` gate to accept both events. * docs(ci): regenerate workflow-status dashboard for ui-full-shards.yml The Check Workflow Status Dashboard CI job (check-workflow-status.yml) failed on the previous commit because the new ui-full-shards.yml didn't have a row in docs/ci/workflow-status.md. Regenerated via `pdm run python scripts/generate_workflow_status.py` (~100 gh API calls) to add the missing row.
59 lines
3.0 KiB
YAML
59 lines
3.0 KiB
YAML
# PR triage labels managed declaratively by .github/workflows/labels-sync.yml.
|
|
# This file is an additive sync — labels not listed here are left untouched.
|
|
# Persistent labels (applied at PR open by .github/workflows/pr-triage.yml):
|
|
- name: external-contributor
|
|
color: 'cccccc'
|
|
description: PR from someone outside the maintainer team
|
|
- name: first-time-contributor
|
|
color: 'c2e0c6'
|
|
description: First contribution to this repo
|
|
- name: bot
|
|
color: 'ededed'
|
|
description: PR opened by an automated account
|
|
- name: needs-rework
|
|
color: 'e99695'
|
|
description: PR needs substantive rework before it can be reviewed in depth
|
|
# Lifecycle labels (toggled per-PR by .github/workflows/pr-triage.yml):
|
|
- name: needs-codeowner-review
|
|
color: 'fbca04'
|
|
description: Awaiting first review from a global codeowner
|
|
- name: awaiting-author
|
|
color: 'd4c5f9'
|
|
description: Codeowner requested changes; ball is with author
|
|
- name: awaiting-codeowner
|
|
color: 'fef2c0'
|
|
description: Author has responded; needs codeowner re-review
|
|
# LDR research trigger labels (used by .github/workflows/e2e-research-test.yml
|
|
# and .github/workflows/issue-research.yml — applied manually by maintainers,
|
|
# auto-removed by the workflow after the run completes).
|
|
# Descriptions are phrased as direct instructions so the AI code reviewer
|
|
# (.github/workflows/ai-code-reviewer.yml) can decide when to apply them.
|
|
- name: ldr_research
|
|
color: '7057ff'
|
|
description: Apply for substantive logic/architecture changes — when in doubt, add it. Runs full LDR research.
|
|
- name: ldr_research_static
|
|
color: '7057ff'
|
|
description: Cheaper variant of ldr_research for routine code changes — favor running this over no analysis.
|
|
# E2E test trigger labels (used by .github/workflows/puppeteer-e2e-tests.yml).
|
|
# Both labels trigger the same Puppeteer suite; descriptions guide the AI
|
|
# reviewer toward running the suite for any PR that touches the web stack.
|
|
- name: 'test:puppeteer'
|
|
color: '0e8a16'
|
|
description: Apply if PR touches UI, web routes, auth, or templates — when in doubt, add it. Runs Puppeteer E2E.
|
|
- name: 'test:e2e'
|
|
color: '1d76db'
|
|
description: Alias for test:puppeteer (same Puppeteer workflow). Apply one; both trigger the same job.
|
|
# Full sharded UI test trigger (used by .github/workflows/ui-full-shards.yml).
|
|
# Invokes docker-tests.yml with strict-mode=true so the 14-way ui-tests matrix
|
|
# runs. Heavy — re-runs the full docker-tests job graph including pytest.
|
|
- name: 'test:ui-full-shards'
|
|
color: '0e8a16'
|
|
description: Apply if PR touches puppeteer test infra or you want all 14 UI shards — costs ~45 min CI time.
|
|
# Human-only signal labels — must NOT be set by any workflow, bot, or AI
|
|
# reviewer. These exist to communicate a human judgement that automation
|
|
# cannot make. If you find a workflow or hook applying one of these,
|
|
# that's a bug — remove the automation, don't extend the label list.
|
|
- name: code-ready
|
|
color: '006b75'
|
|
description: Code looks technically ready; still needs CI + approver. Apply manually — never auto-applied.
|