design/where-are-submitters-routed-to-after-push

[bwalsh]

Feature request: Route GitHub commit status “Details” link to the right post-run UI (workflows + deploys)

Problem

Today the GitHub App’s commit status “Details” link is either generic or inconsistent. After:

• a workflow run (e.g., Argo Workflows / Nextflow), people want fast debugging + traceability
• an app deploy (Argo CD), people want the live deployed state + logs

We should standardize where the “Details” link routes based on what the status represents.

Goals

• Make “Details” immediately useful for triage and auditing
• Keep links stable (shareable, permission-aware)
• Support both workflow success and deploy success (and ideally failure too)

Non-goals

• Replacing existing UIs (Argo UI, Argo CD UI, log stack)
• Designing a full observability platform (we’ll link into one)

---

Option 1: Native console deep-link (best for “single source of truth”)

Route “Details” to the canonical controller UI for the thing that ran.

After workflow success

• ✅ “Details” → Argo Workflows console page for the specific Workflow (namespace/name/uid)

After app deploy success

• ✅ “Details” → Argo CD console page for the specific Application (and revision)

Pros

• Most accurate state, rich metadata (inputs/outputs, DAG, retries, sync status)
• Minimal new infra; mostly link composition
• Clear ownership boundaries (Argo owns the UX)

Cons

• Requires users to have Argo/ArgoCD access and SSO configured correctly
• UIs can be slow or less friendly for “just show me logs”

Implementation notes

• Status payload needs enough identifiers to construct URLs:

  • workflow: namespace + name (and preferably UID)
  • app: application name + repo revision (and maybe sync operation ID)

---

Option 2: Artifact/log-first link (fastest “proof it ran”)

Route “Details” to raw logs/artifacts for quick inspection.

After workflow success

• ✅ “Details” → naive raw logs (S3/MinIO bucket browser path scoped to run/commit)

After app deploy success

• ✅ “Details” → the deployed log (whatever is defined as “deploy output”: e.g., rollout logs, controller output, or a single aggregated log object)

Pros

• Super fast for “what happened” and “show me output”
• Works even if Argo UI is unavailable (as long as object store is reachable)
• Great for lightweight consumers (reviewers, auditors)

Cons

• “Bucket browser” UX is primitive; not Kubernetes-aware
• Hard to correlate across pods/namespaces without conventions
• Permissions and signed URL lifetimes can be tricky

Implementation notes

• Requires a deterministic object layout, e.g.:

  • s3://<bucket>/runs/<repo>/<sha>/<workflowRunId>/...

• For deploy logs, define what “deployed log” means (rollout, pod logs, or CI summary artifact)

---

Option 3: Kubernetes-aware logs browser (best for debugging across systems)

See #90

Route “Details” to a log UI that understands namespaces/pods/labels and can pivot quickly.

After workflow success

• ✅ “Details” → Kubernetes-aware logs browser filtered to:

  • workflow namespace
  • labels like workflows.argoproj.io/workflow=<name> (or equivalent)
  • time range around the run

After app deploy success

• ✅ “Details” → Kubernetes-aware logs browser filtered to:

  • application namespace(s)
  • labels like app.kubernetes.io/instance=<argocd-app> or app=<name>
  • time range around the sync

Pros

• Best day-2 ops experience: search, filter, multi-pod, tail, time windows
• Same UX for workflow + deploy (less cognitive load)
• Great when “success” still needs verification (“did it actually run clean?”)

Cons

• Requires/assumes a log platform (Loki/Grafana, OpenSearch, etc.)
• Filter correctness depends on consistent labeling
• Users may still want the Argo/ArgoCD object page for provenance

Implementation notes

• Standardize labels/annotations across workflow + deploy workloads
• Construct URL with query params (namespace/labels/time range)

---

Definition of Done

• Commit status “Details” URL is deterministic and phase-aware:

  • workflow status routes according to chosen option
  • deploy status routes according to chosen option

• Links include enough context to land on the exact run/deploy (not a generic dashboard)

• Works for at least success and failure (failure can use same routing, just more important)

• Documented in operator/dev docs: “Where does Details go and why?”

---

Acceptance tests

1. Workflow success

   • Given a workflow status created for commit SHA
   • When user clicks “Details”
   • Then it opens the configured target (Argo WF page OR S3 logs path OR k8s log viewer) scoped to that workflow run

2. Deploy success

   • Given a deploy status created for commit SHA
   • When user clicks “Details”
   • Then it opens the configured target (Argo CD app page OR deployed log OR k8s log viewer) scoped to that deploy/sync

3. Permissions behavior

   • If user lacks access to target UI, they get the system’s standard auth prompt/denial (no leaking of sensitive info via URL)

4. Stability

   • The “Details” link remains valid for at least N days (define per org), or uses a stable landing path that can redirect even if underlying run IDs expire

---

--- ---