explore backend policy for CI run/watch UX across GitHub, GitLab, and Codeberg #260

New issue

2026-04-14T21:01:11Z

barrettruth commented

2026-04-14 21:01:11 +00:00

After the GitHub CI summary/watch UX is clarified, we should make an explicit product decision about how Forge wants CI run surfaces to behave across backends.

Right now the backends are not aligned in the same way:

GitHub has a Forge-rendered intermediate run summary path
GitLab exposes different CI view/watch primitives
Codeberg exists as a backend but does not currently participate in the same summary/watch hook surface

That means there are two different questions that should stay separate:

how should the GitHub run summary/watch flow feel?
should Forge normalize CI run UX across backends, or should each backend stay closer to its native CLI semantics?

This issue is for the second question only.

Scope:

inventory the current CI run/log/watch surfaces for GitHub, GitLab, and Codeberg
decide which concepts should be cross-forge and which should remain backend-native
decide whether the repo-wide run flow, PR-scoped checks flow, and live watch flow should intentionally diverge by backend
identify any shared abstractions that are helping versus forcing the wrong UX

Non-goal:

do not block the GitHub-native summary/watch work on cross-backend parity

After the GitHub CI summary/watch UX is clarified, we should make an explicit product decision about how Forge wants CI run surfaces to behave across backends. Right now the backends are not aligned in the same way: - GitHub has a Forge-rendered intermediate run summary path - GitLab exposes different CI view/watch primitives - Codeberg exists as a backend but does not currently participate in the same summary/watch hook surface That means there are two different questions that should stay separate: 1. how should the GitHub run summary/watch flow feel? 2. should Forge normalize CI run UX across backends, or should each backend stay closer to its native CLI semantics? This issue is for the second question only. Scope: - inventory the current CI run/log/watch surfaces for GitHub, GitLab, and Codeberg - decide which concepts should be cross-forge and which should remain backend-native - decide whether the repo-wide run flow, PR-scoped checks flow, and live watch flow should intentionally diverge by backend - identify any shared abstractions that are helping versus forcing the wrong UX Non-goal: - do not block the GitHub-native summary/watch work on cross-backend parity Related: - #176 - #258 - #259

barrettruth commented

2026-04-14 21:36:19 +00:00

Backend audit after the GitHub-native summary work:

Current repo-wide CI run flow is not actually aligned across backends.

GitHub
- repo CI picker is structured (list_runs_json_cmd)
- ops.ci_log() now prefers view_cmd(), so the default run surface is a run-centric summary buffer based on native gh run view
- has steps_cmd() and run_status_cmd(), so in-buffer summaries/logs can refresh with better run/job context
- has explicit repo-run watch via watch_cmd() -> gh run watch
- PR checks picker also has structured checks and can live-tail in-progress jobs
GitLab
- repo CI picker is structured (list_runs_json_cmd)
- no view_cmd() or summary_json_cmd(), so repo CI log goes straight to run_log_cmd()
- that means the default repo-run surface is not a run summary; it is a traced job log chosen from the pipeline
- has repo-run watch via watch_cmd() -> glab ci view -p <pipeline>
- PR checks picker can live-tail in-progress jobs via live_tail_cmd()
Codeberg
- repo CI picker is structured (list_runs_json_cmd)
- no view_cmd() / summary_json_cmd(), so repo CI log goes straight to run_log_cmd()
- no repo-run watch_cmd(), so the repo CI picker has no true watch surface through ops.ci_watch()
- PR checks picker can still live-tail in-progress jobs via live_tail_cmd()

So the mismatches are:

GitHub repo runs open a run-centric summary first; GitLab and Codeberg repo runs go straight to logs.
GitHub has a dedicated repo-run watch surface; Codeberg does not.
PR checks and repo CI are already different concepts everywhere, but the degree of separation varies by backend.
Shared picker labels (ci, watch, log) hide materially different backend behaviors.

Recommended next slice for #260:

decide explicit product policy for repo-wide CI runs:
- either keep backend-native defaults
- or normalize repo-run behavior across backends
if we keep backend-native defaults, document the divergence and tighten wording in picker labels/docs
if we normalize, the first concrete question is whether GitLab/Codeberg should gain a run-summary layer, or GitHub should move back toward direct log/watch behavior

My recommendation is to keep backend-native defaults and make the divergence explicit, rather than forcing all backends into the GitHub run-summary model.

Backend audit after the GitHub-native summary work: Current repo-wide CI run flow is not actually aligned across backends. - GitHub - repo CI picker is structured (`list_runs_json_cmd`) - `ops.ci_log()` now prefers `view_cmd()`, so the default run surface is a run-centric summary buffer based on native `gh run view` - has `steps_cmd()` and `run_status_cmd()`, so in-buffer summaries/logs can refresh with better run/job context - has explicit repo-run watch via `watch_cmd()` -> `gh run watch` - PR checks picker also has structured checks and can live-tail in-progress jobs - GitLab - repo CI picker is structured (`list_runs_json_cmd`) - no `view_cmd()` or `summary_json_cmd()`, so repo CI log goes straight to `run_log_cmd()` - that means the default repo-run surface is not a run summary; it is a traced job log chosen from the pipeline - has repo-run watch via `watch_cmd()` -> `glab ci view -p <pipeline>` - PR checks picker can live-tail in-progress jobs via `live_tail_cmd()` - Codeberg - repo CI picker is structured (`list_runs_json_cmd`) - no `view_cmd()` / `summary_json_cmd()`, so repo CI log goes straight to `run_log_cmd()` - no repo-run `watch_cmd()`, so the repo CI picker has no true watch surface through `ops.ci_watch()` - PR checks picker can still live-tail in-progress jobs via `live_tail_cmd()` So the mismatches are: 1. GitHub repo runs open a run-centric summary first; GitLab and Codeberg repo runs go straight to logs. 2. GitHub has a dedicated repo-run watch surface; Codeberg does not. 3. PR checks and repo CI are already different concepts everywhere, but the degree of separation varies by backend. 4. Shared picker labels (`ci`, `watch`, `log`) hide materially different backend behaviors. Recommended next slice for #260: - decide explicit product policy for repo-wide CI runs: - either keep backend-native defaults - or normalize repo-run behavior across backends - if we keep backend-native defaults, document the divergence and tighten wording in picker labels/docs - if we normalize, the first concrete question is whether GitLab/Codeberg should gain a run-summary layer, or GitHub should move back toward direct log/watch behavior My recommendation is to keep backend-native defaults and make the divergence explicit, rather than forcing all backends into the GitHub run-summary model.

Sign in to join this conversation.