Question - How to resolve the colors easily when manually writing comments?

[Vadorequest]

I'm trying to integrate LH reports within my GH actions.

Our workflow is as follow:

1. We deploy on Zeit
2. We wait for the Zeit deployment to be done
3. We run LH audit

We use the push event, because pull_request has severe limitations. Because of that, we have to comment on the PR ourselves, because prCommentUrl option doesn't exist.

Currently, our comment works, but colors are hardcoded (i.e: green) and I wonder how we could easily resolve the right color. I see you're using JS but I'm not familiar with bash and I'm not sure how to avoid code duplication.

![](https://img.shields.io/badge/Accessibility-${{ fromJson(steps.lighthouseCheck.outputs.lighthouseCheckResults).data[0].scores.accessibility }}-green?style=flat-square)

I know this isn't so much related to lighthouse-check-action, but if you know of a good example/tutorial about how to run JS through github actions, it may be helpful.

Also, I think the prCommentUrl option would be a great addition, for people who cannot use pull_request trigger.

PR: https://github.com/UnlyEd/next-right-now/pull/109

      # Add a comment to the PR with lighthouse report
      - name: Comment PR (LightHouse report)
        uses: peter-evans/create-or-update-comment@v1
        with:
          token: ${{ secrets.GITHUB_CI_PR_COMMENT }}
          issue-number: ${{ steps.pr_id_finder.outputs.number }}
          # Report provided by steps.lighthouseCheck.outputs.lighthouseCheckResults is a string and need to be transform into an object.
          # Then, using badges with results provided by `data[0].scores.<category>`
          # data is an array containing results of every urls tested. Thankfully, we only test one url so we don't care about the index.
          # See "fromJson" documentation: https://help.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#fromjson
          body: |
            [GitHub Actions] - **Lighthouse report** for ${{ env.ZEIT_DEPLOYMENT_URL }}
            ![](https://img.shields.io/badge/Accessibility-${{ fromJson(steps.lighthouseCheck.outputs.lighthouseCheckResults).data[0].scores.accessibility }}-green?style=flat-square) ![](https://img.shields.io/badge/Best%20Practices-${{ fromJson(steps.lighthouseCheck.outputs.lighthouseCheckResults).data[0].scores.bestPractices }}-green?style=flat-square) ![](https://img.shields.io/badge/Performance-${{ fromJson(steps.lighthouseCheck.outputs.lighthouseCheckResults).data[0].scores.performance }}-orange?style=flat-square) ![](https://img.shields.io/badge/Progressive%20Web%20App-${{ fromJson(steps.lighthouseCheck.outputs.lighthouseCheckResults).data[0].scores.progressiveWebApp }}-orange?style=flat-square) ![](https://img.shields.io/badge/SEO-${{ fromJson(steps.lighthouseCheck.outputs.lighthouseCheckResults).data[0].scores.seo }}-green?style=flat-square)

[adamhenson]

Hi @Vadorequest - thanks for opening this. I wasn't aware of this scenario. I think the best step forward will be to investigate ways of supporting the push trigger to comment on PRs... to perhaps incorporate your example. I'm not sure how high of a priority that investigation will take, but will keep this open for others to chime in.

To solve your problem, perhaps you could set environment variables programmatically as its own step based on scores... using workflow commands.

[Vadorequest]

Meanwhile, supporting the existing prCommentUrl and passing it down to lighthouse-check would solve the issue, by providing a simple workaround.

I've played with pull_request trigger a bit and here are the most annoying limitations I've found:

• There is no way to trigger when a PR is merged into another - See https://github.community/t/pull-request-action-does-not-run-on-merge/16092?u=vadorequest
• It won't trigger when the PR is conflicting with its base branch - See https://github.community/t/run-actions-on-pull-requests-with-merge-conflicts/17104/2?u=vadorequest

Thus, we went from push to pull_request and went back to push again, due to the above limitations.

[adamhenson]

Interesting, thanks for providing that! Right, I understand now - we need to expose prCommentUrl as an option in this GitHub Action.

That should be pretty simple, I'll make sure this gets in the next update and will report back.

[Vadorequest]

Awesome, thank you!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[adamhenson]

Sorry this took so long. @Vadorequest - You can now manually set commentUrl like this example. I chose to call it commentUrl vs prCommentUrl because it's added on a commit vs on a PR. Released in v2.0.3. Thanks for reporting.

[Vadorequest]

Thanks! Just to clarify, does it need a accessToken defined? The example uses one, I thought it was only required when using pull_request mode.

[adamhenson]

Yes, @Vadorequest - under the hood we still populate prCommentUrl used by lighthouse-check. In lighthouse-check the naming is prCommentUrl and prCommentAccessToken, but it's really the just the naming that is bad. Someday, hopefully I can change it to just commentUrl and commentAccessToken.

To post comments we use the GitHub REST API directly, and the access token is required for authorization.

https://github.com/foo-software/lighthouse-check/blob/fb520470319970503b7dbd58c3b1d1086304bcf7/src/postPrComment.js#L88-L102

[Vadorequest]

That's what I assumed, works like a charm :)

https://github.com/UnlyEd/next-right-now/pull/139#commitcomment-40910846

[adamhenson]

Awesome!