Add new affected/changed PR(s) column to log overview table on the Developer portal at Mend.io

[HonkingGoose]

Tell us more.

Intro

If you notice a problem with a Renovate PR right away, it's easy to find the correct log from the https://developer.mend.io/ site. You just select the latest log. 😄

But finding the correct log is hard when you notice the problem later. Now you need to select each ID in turn, select the INFO debug level to declutter, and read the PR number in the log.

I tried finding the logs for a later Renovate run myself, and it's difficult! 🙈

Proposal

Add a new column to the log overview table, that lists the affected PR(s). Mockup time:

ID	PR(s) affected	Engine	Reason	Completed At	Status ?
3	None	renovate	hourly	an hour ago	Done
2	Created #28784	renovate	requested	2 hours ago	Done
1	Updated #28786	renovate	hourly	3 hours ago	Done

I got this idea after thinking about the problems a user had to find the correct logs in discussion #29004.

Link to the PRs?

A link to the PR(s) in the table would be handy. But this may get complicated fast, as you may need to link to GitHub/GitLab, Bitbucket, etc. For the Mend hosted app you could assume the GitHub.com domain, I think?

Possible problems with the new feature

• It costs too much compute time to "read log and grab PR number"
• How can the site know if Renovate changed/updated any PRs?
• How to find the correct PR number from the log?
• Coupling of log message/format to the "read log and grab PR number" code
• Privacy/security concerns with the site "reading the logs"

Outro

Let me know what you think! 😄

[aherrmann]

This is precisely what I was missing in the situation described in the linked discussion. An extra column in the jobs table that states which PR was affected by each job would make it very easy to pick out the relevant job for a given issue related to a PR.

[HonkingGoose]

Having an affected branch column would probably be handy too. With some kind of errors you don't get a PR, because Renovate got stuck before it can create a PR. But that might make the table too wide.

[rarkins]

In theory this could be many PRs, even dozens. How should the UI look in such cases? Happy paths are easy, the rest is hard

[HonkingGoose]

I discussed this some more with @rarkins on Slack. Here's my comment:

Maybe better search and filtering would help more than a table entry. If you could search or filter for:

• time when Renovate ran (between x start time and y end time)
• Running time of Renovate for a run (to find really short or really long runs)
• branch names (renovate/broken-branch)
• PR numbers
• dependency names
• package manager names
• other things that might help filter/search that I'm forgetting to list

Then you probably do not need a table listing the PR number or branch names.

@rarkins replied:

Exactly. Although it's not common UX, you can let people search and filter based on fields which aren't displayed in the table

If you limit yourself to what's in the table, then you're limiting yourself based on width of screens

I was thinking that a filter which lets you search by PR number, and it even conveniently shows the last 5 or so PR numbers for you to click on, then it could be better

Within the table I think the most we could display is a count of branches created/updated and PRs created/updated

To summarize: I think we want to add the branch count and PR count in two new columns in the log overview page, and work on better search/filtering?