fix(gha): displays extra data in gha output

[davidg-dq]

This PR adds additional data to the output of the axe-devhub-action.

Note: I may need to change the names of the variables we're outputting to be in line with what we use, but I'm not sure of this yet. @Zidious @dbjorge - Perhaps one of you can guide me on this?

QA Notes

1. Use axe-devhub-action in your CI process
2. Observe action output after a run

ref: #1219

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ dbjorge
✅ davidg-dq
❌ David Garrett

---

David Garrett seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Zidious]

Note: I may need to change the names of the variables we're outputting to be in line with what we use, but I'm not sure of this yet. @Zidious @dbjorge - Perhaps one of you can guide me on this?

In terms of what's being outputted to the GHA terminal or what's intended to be outputted as a comment on the PR?

[dbjorge]

A few suggestions inline. We probably want to defer merging this until after the updated API releases to prod to avoid breaking users that are referring to main instead of v1 (ideally folks shouldn't be doing that, but we should probably avoid knowingly breaking folks that are anyway)

[dbjorge]

new_issues, resolved_issues, difference_in_page_states are all only meaningful if there was a previous session for us to compare to. In the comparable summary UI we use for list items in the devhub frontend's "commits" view, we omit them if there wasn't a previous session.

I wonder if it might make more sense for us to update the walnut route to specify those properties as undefined or null if there wasn't a previous session, and to omit them here (from both GITHUB_OUTPUT and stdout) if so.

[davidg-dq]

I think that's a great idea. Would you like me to go ahead and work on modifying the output from the walnut route?

[dbjorge]

I think that'd be good, but it doesn't have to block this PR

[davidg-dq]

Note: I may need to change the names of the variables we're outputting to be in line with what we use, but I'm not sure of this yet. @Zidious @dbjorge - Perhaps one of you can guide me on this?

In terms of what's being outputted to the GHA terminal or what's intended to be outputted as a comment on the PR?

In terms of what is being added to the GITHUB_OUTPUT for subsequent steps to access. Should I rename variables to use the last_run.... naming convention or just stick with what we have, so we don't break anyone's GH actions?

Addressed comments

[dbjorge]

I think we should avoid making a breaking change.

[davidg-dq]

@dbjorge @Zidious
It looks like cla-assistant isn't recognizing that my GH account has signed the CLA. I've clicked "recheck" several times and nothing happens, but when I go to the link, it shows that I've accepted. I've also added my email to my local git config. Any ideas? Maybe I need to create a new branch with a new PR since my earlier commits didn't have my email address attached? Or perhaps it's okay for us to bypass this for this PR?

[dbjorge]

@davidg-dq I'll bypass it for this PR. If you did want to fix it up, you'd need the corrected email to apply to all the commits in the PR, which you could do either by amending the commits or by rebasing after having updated the email config (either way you'd need to force push to the PR branch)

[davidg-dq]

@davidg-dq I'll bypass it for this PR. If you did want to fix it up, you'd need the corrected email to apply to all the commits in the PR, which you could do either by amending the commits or by rebasing after having updated the email config (either way you'd need to force push to the PR branch)

Thank you!