Zak Siddiqui
opened 1 day ago
-
Thanks for writing this up. Today the pull request Activities tab lists each push as an update, and each commit row shows author, message, signature, date, and hash — but not build status. The project Commits page already shows a clickable overall status icon (opens the job list). The pull request header also shows jobs for the current head (required jobs marked with
*), so this request is specifically about seeing status next to each commit in Activities without leaving the pull request.A few choices will make the feature issue precise. Reply with option letters (for example
1A, 2A, 3A, 4A), or say to go with the recommendations.1. What should the status on each commit represent?
- A. Overall status of all jobs for that commit (same meaning as on the Commits page)
- B. Only jobs associated with this pull request
- C. Only required / merge-check jobs
Option Pros Cons Recommendation A Matches the Commits page; one familiar meaning of “build status”; reuses the existing commit-status widget Can include jobs that do not affect mergeability Recommended. Reviewers already learn this meaning on the Commits page, so Activities would stay consistent. B Stays focused on CI that ran in this PR Intermediate commits may have little or no PR-linked builds; status can look “empty” compared with the Commits page Use only if you care solely about PR-triggered CI, not commit CI in general. C Directly answers “can this commit pass merge checks?” Hides optional jobs; differs from the Commits page Use only if the goal is merge-gate status rather than full CI visibility. 2. How should the status be shown and opened?
- A. Same control as the Commits page: overall status icon; click opens the job list (and can run jobs)
- B. Status icon only (tooltip); click goes to the commit page
- C. Per-job icons on every commit row (like the job list in the PR header)
Option Pros Cons Recommendation A No extra navigation; same interaction as Commits / commit detail; existing UI Slightly busier Activities rows Recommended. This is the smallest consistent change and still lets you inspect or run jobs in place. B Quieter list; one click to the commit you would visit today Extra navigation to see which job failed Prefer only if you want Activities to stay as compact as it is now. C See each job without opening a dropdown Crowded rows when a commit has many jobs; duplicates the PR header pattern at a much denser scale Too heavy for a commit list that can include many commits per update. 3. Which commits in Activities should show status?
- A. Every commit listed in Activities (including older pushes and rebased commits)
- B. Only currently relevant (non-rebased) commits
- C. Only the head commit of each update/push
Option Pros Cons Recommendation A Matches “next to each of the commits in Activities”; historical pushes keep their CI Rebased rows may still show status for old hashes; more icons on long histories Recommended. That matches the request as written. Rebased commits are already marked as rebased, so old status remains understandable. B Avoids status on commits that are no longer on the PR Hides CI for force-pushed history, which is often what you want when diagnosing “what broke after the rewrite” Use if Activities should only reflect the current series. C Least clutter; status for “what was pushed” rather than every commit Does not satisfy “each of the commits”; intermediate commits still need the Commits page Too narrow for the stated goal. 4. Where should the icon sit on the row?
- A. Beside the commit message (same place as on the Commits page)
- B. Beside the hash on the right
- C. Between signature and date
Option Pros Cons Recommendation A Same visual language as the Commits page Competes slightly with message text on narrow widths Recommended. Reviewers already look there for status. B Keeps the message column clean Hash/actions are already on the right; easy to miss Fine if you want status treated as an “action,” not part of the commit summary. C Groups status with other small metadata icons Signature is a different kind of signal; mixed meanings Avoid unless you specifically want metadata icons clustered.
Draft New Feature issue (using the recommendations: 1A, 2A, 3A, 4A)
Title: Show commit build status in pull request Activities
Type: New Feature
Description:
On the pull request Activities tab, each update lists the commits from that push. To see build status for a commit, you currently have to open the project Commits page (or the commit itself). The PR header already shows jobs for the current head, but not for the other commits in the activity history.
Expected behavior:
- Show the same overall commit build-status control used on the project Commits page next to each commit listed in PR Activities (including older updates and rebased commits).
- Place the icon beside the commit message.
- Clicking it should open the job list for that commit (same as Commits), in the context of this pull request.
- If the commit has no jobs, hide the control (same as Commits).
Reply with your option letters, or confirm this draft and I will file it as a New Feature issue.
-
Answers
1A, 2A, 3A, 4A
-
-
@zaakiy Created the follow-up New Feature issue from your answers (1A, 2A, 3A, 4A) and closing this Question.
Tracked for implementation as issue #3028.
-
Previous Value Current Value Open
Closed
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
Inside pull requests, there is activity history which shows each commit. If I want to see what the build status is for that commit, I need to go to the commits page.
I would rather quickly see the build status next to each of the commits in the
Activitieslist in the pull request.Help me create an issue for this work.
Don't assume. Ask high-level clarifying questions if needed.