Provide link in PR body to specific *run* logs to facilitate self-debugging

[abernix]

What would you like Renovate to be able to do?

The Dashboard logs for a Renovate run are pretty useful, but triangulating PRs that have been raised to actual job lobs can be a bit tedious. Providing a link to the particular Dashboard run in the body of the PR (rather than just a link to the Dashboard, generally), would be very useful in self-debugging.

For example, on apollographql/apollo-server#4998, there was an Artifact update problem which mostly highlighted the symptom, but necessitated going to the actual run job to determine what constraints were in place that could help explain how the version of npm and node that were going to be run was getting resolved. In this particular case, I resorted to opening an issue on this repository (#9036) which pointed the problem back to me, but I definitely didn't quite have enough time to dig through the logs to find the specific log that would have helped me. I believe if I could have found the log that generated this actual PR that I may have been able to find the docker run invocation more easily (and possibly the constraints as well). It's plausible that this may have prevented me from raising an issue.

Here's a screen grab of this, just in case the issue gets updated/closed by Renovate, but on this PR there is a link to the "View repository job log here.".

If there was also a link that said, View this PRs (last?) job log here, that might be helpful!

An alternative, possibly more defensive mechanism (which I believe would have allowed me to avoid raising the issue at all, in this case), would have been some sort of debug tool or output that would display the derived Renovate configuration including hints as to where inherited configuration bits had come from (i.e., in this case I could maybe see that the force attribute on my renovate.json5 was in effect.). Since the job log might be a better place to start with this output, I still defer to my original suggestion above to put a job-specific link in the PR body, though, if at all possible!

[rarkins]

Renovate applies package rules and merges cascading config potentially hundreds of times every run, so logging that would be pretty overwhelming (your defensive mechanism approach).

Because job logs are deep-linkable, we could in theory deep link to a job, however the challenge is (a) which job log to link to, and (b) how to make sure we don't keep updating it unnecessarily each time there's a new job.

I think in most cases I think the most important job log would be the one which last committed, which is not state we currently keep between runs.

I had been thinking previously and maybe have an issue open already for it, but we could potentially use hidden html comments in the PR body to keep a few bits of state like this, e.g. the first and last commit run IDs, and the PR creation job ID. We'd then need to retrieve those from the each open PR body each run so that we don't accidentally override them when updating the PR body later for any reason.

Final point, this request is essentially an app request so not related to this repo, however we'd need to do some work in this repo first to make it possible and expose a field like lastCommitJobId for templating.

[viceice]

If pr is created with not-pending, we can't safe initial commit run. 🤔

[rarkins]

We could store in commitMessageBody but it's a little hacky. Alternative - a custom status check which links to the job log? It's tied to the commit hash so seems to fit.

[viceice]

Yeah, commit status seems best solution here