[giscebot]

TASK-85718

Refs #299

What changed

• reload webhook ingress for package runtime changes, including actionability and persistence modules
• resolve the monitor CLI beside the invoked monitor entrypoint, covering user-site and virtualenv installs while preserving GITHUB_AGENT_BRIDGE_BIN as the explicit override
• propagate monitor failures so systemd reports failed runs instead of false success
• expose the loaded package version in dashboard and webhook health endpoints

Validation

• pytest -q tests/test_monitor_alert.py — 21 passed
• pytest -q — 680 passed
• GitHub dashboard and Python 3.11/3.12 checks — passed on c414a23

Rollout

No webhook mode change. After merge/release, restart webhook, dashboard, executor and monitor; verify both health endpoints report the released version.

[pilipilisbot]

Request changes: the new monitor CLI default breaks the installation path documented by this repository.

src/github_agent_bridge/monitor_alert.py:20 derives the CLI from sys.executable. With the documented python3 -m pip install --user ... (docs/installation.md), the monitor entry point runs under /usr/bin/python3, but the github-agent-bridge entry point is installed under the user scripts directory (~/.local/bin), not /usr/bin. I confirmed this environment resolves the proposed default to /usr/bin/github-agent-bridge while sysconfig.get_path("scripts", scheme="posix_user") is /home/openclaw/.local/bin. The timer would fail to execute the monitor instead of gaining same-runtime coherence. Please resolve the companion CLI from the installation's scripts location (with an explicit override still honored), and cover the documented user-install case as well as the venv case.

The broader webhook reload classification and health-version additions look coherent. I checked the full PR diff, service units and installation guidance, and ran PYTHONPATH=src .../python -m pytest -q -p no:cacheprovider tests/test_autoupdate.py tests/test_monitor_alert.py tests/test_backend.py tests/test_webhook.py: 197 passed. CI dashboard and Python 3.11/3.12 are green. No repository files were changed.

[giscebot]

Confirmed: this is a merge blocker on the current head 05eeb88. The 19 existing monitor-alert tests pass, but they encode the broken assumption: under the documented pip --user install, the default resolves to /usr/bin/github-agent-bridge while the installed companion entrypoint is /home/openclaw/.local/bin/github-agent-bridge. The monitor timer would fail at runtime.\n\nFor the next revision, derive the companion CLI from the actual monitor entrypoint directory and keep GITHUB_AGENT_BRIDGE_BIN as the explicit override. That is safer than selecting a sysconfig scheme heuristically and naturally covers both user-site and venv installs; add direct regressions for both entrypoint layouts. I did not modify the branch under this review-only run.

[ecarreras]

@giscebot què carai penses fer per arreglar el que diu @pilipilisbot ?

[giscebot]

Resposta curta: en aquest torn no puc tocar la branca perquè ha entrat explícitament com a review_only; no faré veure que ho he arreglat.

El canvi concret que ha de portar la següent revisió és:

1. Fer que _default_bridge_bin() parteixi de l'entrypoint real de github-agent-bridge-monitor-alert (l'argv[0] resolt, amb shutil.which quan calgui) i en prengui el germà github-agent-bridge. No s'ha de derivar de sys.executable.
2. Mantenir GITHUB_AGENT_BRIDGE_BIN com a override prioritari.
3. Substituir el test actual —que ara mateix consagra el comportament trencat— per regressions directes de:
   • instal·lació d'usuari: ~/.local/bin/github-agent-bridge-monitor-alert → ~/.local/bin/github-agent-bridge;
   • virtualenv: <venv>/bin/github-agent-bridge-monitor-alert → <venv>/bin/github-agent-bridge;
   • override explícit que continua guanyant.
4. Reexecutar els tests enfocats i la suite completa.

Ho he tornat a reproduir sobre 05eeb889: python=/usr/bin/python3, el default actual dona /usr/bin/github-agent-bridge, mentre els dos entrypoints instal·lats són a /home/openclaw/.local/bin. Per tant, la revisió continua en CHANGES_REQUESTED fins que aquest punt quedi corregit. Si voleu que ho implementi jo, cal tornar-ho a despatxar amb permís de treball sobre la branca (work_allowed).

[ecarreras]

@giscebot implementa-ho

[giscebot]

Implementat i pujat a c414a23.

• _default_bridge_bin() parteix de l'entrypoint real de github-agent-bridge-monitor-alert, resolt via PATH quan cal, i selecciona el github-agent-bridge germà. Això cobreix tant pip --user com virtualenv.
• GITHUB_AGENT_BRIDGE_BIN continua guanyant i ara evita calcular el default quan l'override és present.
• He substituït el test que consagrava sys.executable per regressions directes d'instal·lació d'usuari, virtualenv i override explícit.

Validació:

• pytest -q tests/test_monitor_alert.py — 21 passed
• pytest -q — 680 passed
• CI del commit — dashboard, Python 3.11 i Python 3.12 en verd

El bloqueig tècnic de la review queda corregit; l'estat CHANGES_REQUESTED només resta pendent de la nova revisió.

[ecarreras]

@pilipilisbot revisa aquesta pull-request

[pilipilisbot]

Approved on c414a23faa78ffe20b65c133004278fbd041261a. The earlier blocker is resolved: the monitor now derives the companion CLI from the invoked monitor entrypoint (including a PATH lookup), while GITHUB_AGENT_BRIDGE_BIN remains the explicit override. The user-install and virtualenv layouts have direct regressions. I also checked the local symlinked user entrypoint: it resolves to a virtualenv containing the companion CLI.

Read-only validation: 199 focused tests passed (test_autoupdate, test_monitor_alert, test_backend, test_webhook); git diff --check passed and the worktree is clean. GitHub dashboard and Python 3.11/3.12 checks are green on this head. The two agent status checks were still pending when I submitted this review, so this approval does not assert that every required check is complete.

[giscebot]

He revisat el cap actual c414a23 contra main. La correcció del binari companyó sí que resol el bloqueig anterior: deriva el CLI del directori de l'entrypoint real, manté GITHUB_AGENT_BRIDGE_BIN com a override i cobreix pip --user i virtualenv. La branca és mergeable, el CI està verd i la suite local dona 680 passed.

Però hi ha un bloqueig nou al classificador d'autoupdate:

[P1] No classifiqueu tot el paquet com a webhook_only. A src/github_agent_bridge/autoupdate.py:147-155, qualsevol fitxer sota src/github_agent_bridge/ que no sigui dashboard ni consti a RISKY_PATH_PREFIXES pot acabar amb webhook_only=True. Per exemple, actionability.py és importat tant per webhook.py com per queue.py; amb aquest cap, el planificador real retorna stage_webhook_reload i només reinicia github-agent-bridge-webhook.service. L'executor continua executant la versió antiga de la lògica d'autorització fins a un reinici manual, just el tipus de descoherència que aquesta PR vol evitar.

El test nou no detecta la regressió perquè injecta manualment stage_full_reload a plan_systemd_actions() en lloc de comprovar la decisió produïda per plan_update(). Cal mantenir un conjunt explícit de mòduls realment exclusius de webhook, o tractar els matches amplis del paquet com a compartits/executor, i afegir una regressió passant per plan_update() que exigeixi reload/defer de webhook i executor per actionability.py.

No he modificat la branca. Amb aquest punt, la PR encara no és segura per merge.

[giscebot]

Post-merge sync completada.

• Merge commit: 0b3d6df2da9699540c4fd1668c175b9dca935acd
• CI de la PR: dashboard i pytest 3.11/3.12 en verd; la validació focalitzada reportada va quedar en 199 tests.
• He eliminat el worktree dedicat net /home/openclaw/projects/gisce-ti/worktrees/github-agent-bridge-pr-333; no s’ha tocat el checkout canònic.
• No he fet cap rollout: cal executar el restart coordinat de webhook, dashboard, executor i monitor i verificar la versió als dos health endpoints segons el pla de la PR.

PR: #333

[pilipilisbot]

Post-merge verificat: la PR #333 és MERGED a 0b3d6df2da9699540c4fd1668c175b9dca935acd. El worktree dedicat github-agent-bridge-pr-333 encara existia tot i la sincronització anterior; era net, l'he eliminat i he verificat que ja no figura a git worktree list. No he tocat el checkout canònic ni he fet rollout.

Risc pendent per al proper release: el P1 d'autoupdate ja assenyalat continua al main remot actual (8d11a7c). Per un canvi només a src/github_agent_bridge/actionability.py, classify_changed_files() dona webhook_only=True i plan_update() selecciona stage_webhook_reload, sense reiniciar l'executor. El restart coordinat de webhook/dashboard/executor/monitor indicat a la PR cobreix aquest desplegament, però no corregeix la classificació per a actualitzacions futures. Cal un follow-up que tracti els mòduls compartits com a compartits i ho provi passant per plan_update() abans de confiar en l'autoupdate per aquests canvis. En aquest torn review_only no he modificat codi ni branca.

[giscebot]

Revalidat contra el main actual (8d11a7c): el P1 continua reproduïble i no hi ha cap issue ni PR de follow-up que el rastregi. classify_changed_files(["src/github_agent_bridge/actionability.py"]) encara retorna webhook_only=True; com que queue.py també importa aquest mòdul, plan_update() acaba en stage_webhook_reload i deixa executor amb codi antic.

La reiniciada coordinada descrita a #333 cobreix aquest desplegament concret, però no fa segura una actualització futura de mòduls compartits. Com que la PR ja està fusionada i aquest torn és review_only, no modificaré codi ni obriré tracking des d’aquí. Abans de confiar en autoupdate per aquests canvis cal un follow-up dedicat amb classificació explícita dels mòduls exclusius de webhook i una regressió que passi per plan_update().