FR: monitor CI triggered by PR merge

[jinnatar]

Feature Request

Describe the problem that led to you needing this feature

During a PR I can observe the progress of CI very well, but once it's merged there's more CI triggered that I cannot similarly observe since there is no PR number attached to it or valid URL I could give. I want to observe the merge runs as well since they may be very long running and fail due to flaky dependencies. A quick targeted restart would save the day, but first I need to be able to observe it.

Describe the solution you'd like

While it would be lovely to detect the effects of a PR merge from the PR number or URL and follow those CI pipelines automatically, it's probably less surprising and easier to implement if instead it was supported to provide the URL of a running actions run instead. This would be a generic solution that would allow tracking any arbitrary run with a URL such as: https://github.com/kanidm/kanidm_ppa_automation/actions/runs/25850359207

Describe alternatives you've considered

I could follow along on the web, but that comes with it's own set of problems and sometimes GH just forgets to refresh the page.

Additional context

N/A

[chicks-net]

Thanks for filing this issue and bringing this idea up. I've run into this problem as well.

Since we can auto-detect the repo, would it make sense for gh observer to display all of the running or recently finished jobs that are running on the repo outside of a PR context? We already take a PR URL as an arguments, so a job URL would muddle the interface some. The job URL idea also means you'd only be watching the one job and other jobs could have run and finished while you're watching the one job.

How does this sound to you?

[jinnatar]

I tend to like the "principle of least surprise" where features and processes feel like they are a direct and logical consequence of your actions and there's only magic that stays within that principle. Finding the right job from the PR number is great, but it's not easy to guess what the user intended without one: Did they want all currently running jobs? Or all that have run recently even if already complete? Or perhaps ones they caused to trigger? It's difficult to infer what they wanted without adding a bunch of explicit cli flags, which could be very non-surprisy, but also unwieldy. The run URL would be very explicit without needing much in terms of flags, but it does require the dev to first find what the URL is which requires you to go find that browser anyway. One further complication is that I'm using jj instead of git so your feature branch detection etc fails completely because it's just a very different way of working, but with a pr number it still works for me because that has an explicit definition bypassing the magic that assumes git.

Long story short, my gut feeling is that perhaps a good middle ground would be that gh observer list would get a list of detected pipelines and their associations that you may be interested in, say first those detected from feature branches, then open PRs in order of run start time and finally main branch runs from today. List their PR & run IDs, highlight shortest unique prefix in red and then gh observer <prefix> gets you observing that run. A mix of prioritization magic & explicit requests.

[chicks-net]

Sorry about the jj incompatibility, but that sounds like something I'd like to fix.

For now, I'm going to focus on solving this in the way you originally suggested by accepting the job URL and working from there. If there are any other recently running jobs that aren't PR-specific I'll try to show those too.

[chicks-net]

#267 is now release v2.4 -- it accepts the run URL we've mentioned several times. What do you think about this?

[jinnatar]

It works well from what I can see and definitely solves my problem!

[chicks-net]

Do you want to try v2.5? I've tried to add jj compatibility in #273.