Support github job summaries as an output destination

[klundberg]

Given github recently added support for outputting markdown that gets rendered to job summaries (https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/), it'd be nice if Danger supported this as an option for where its output can go. That'd make possible to see Danger's output in a github action without needing to grant access to post to a PR with an api token.

[orta]

For Danger JS I added it as an optional DSL attribute: danger/danger-js#1280

I tried using checks in a similar manner as you're recommending and largely regretted it in danger js, so didn't opt to build it that way this time. I'm not against folks trying it in danger ruby though, so long as it's thoroughly tested

[sandstrom]

I was about to implement danger in our repo, noticed that I needed to add a dedicated user/bot, and then thought about the new job summary and wanted to see if that's supported.

You mentioned elsewhere that you're "potentially open to having the main comment in the job summary if someone can make a good case for it".

Check output

You mention you tried using the checks output, but regretted it. Why did you regret it?

Was that the output object with the summary markdown string? (https://docs.github.com/en/rest/checks/runs#update-a-check-run)

Arguments for job summary support

• No need to setup a dedicated Github user. Less work to set it up on Github Actions, which I'm guessing is where a majority or more are running this.
• Other linting/checks/tests generally won't output stuff to the main PR thread. Instead, you have to click the failed check to see details. Basically more symmetry across tests, linting and danger.

Aligning our discussion

Just to make sure we're talking about the same thing, what I'd like is if the whole comment that goes into the PR today, would instead go into the job summary. In other words, this block:

[orta]

Not getting feedback inside the PR (aka using checks) meant that any warnings/info were ignored by contributors , the same issue would happen with GitHub job summaries as they are quite hard to get to if you just have one job, which is a very typical CI setup - for example this PR: danger/danger-js#1281 sets the job description to 'looking good' - it's 3-4 clicks to find that info

I know you pitch this as a feature, but for me that's a big detraction from the tool.The lack of visibility basically makes danger much less actionable outside of only giving blocking feedback, which is only a subset of what folks use danger for

That said, it is a pretty cool idea to do this when there's not GitHub access token but given how easy it is to use GitHub Actions and the default access token provided by actions it might not be worth the documentation and support

[sandstrom]

Good points, I totally understand! Agree that having them buried could lead to all info/warnings being ignored, which is definitely not desired.

I thought a dedicated user [bot] was always needed, but I see now that it says "Set DANGER_GITHUB_API_TOKEN to secrets, or you can also use GITHUB_TOKEN.", which would alleviate my main concern above. I'll try that out and see if I can get it working.

Thanks for an awesome tool! 🏅