GoogleChrome / lighthouse-ci

Automate running Lighthouse for every commit, viewing the changes, and preventing regressions
Apache License 2.0
6.41k stars 646 forks source link

GitHub Status Checks is not seen in PR Action comment #859

Open zi-gae opened 1 year ago

zi-gae commented 1 year ago

I love that this repo exists, and the great work you're putting in here

I'm having issues with getting the GitHub Status Checks working when following the docs I finished the execution success and install LightHouse CI GitHub App, but I can't see page performance

Screenshot

Install App

image

PR Action comment

image

code is here.

// .lighthouserc.js
module.exports = {
  ci: {
    collect: {
      startServerCommand: 'yarn start',
      startServerReadyPattern: 'ready on',
      url: ['http://localhost:4000/union'],
      numberOfRuns: 1,
      settings: {
        preset: 'desktop',
      },
    },
    upload: {
      target: 'temporary-public-storage',
    },
    server: {},
  },
};
// package.json
"script": {
  "light-house": "lhci autorun --config=./.lighthouserc.js",
  ...,
}
# github actions
name: CI
on:
  pull_request:
    branches:
      - '**'
jobs:
  lighthouseci:
    env:
      deploy_target: 'prod'
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
    runs-on: self-hosted

    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - name: Set NPM
        run: |
          echo @myrealtrip:registry=https://npm.pkg.github.com/ > .npmrc
          echo //npm.pkg.github.com/:_authToken=$NPM_TOKEN >> .npmrc
      - run: cat .npmrc
      - run: npm i -g yarn
      - run: yarn
      - run: yarn build
      - run: yarn light-house
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
Yuriy-Glebov commented 1 year ago

Seeing the same issue, also unable to access GitHub CI App properties.

lpeabody commented 1 year ago

I had the same issue and I found adding the following to the pertinent workflow solved the dilemma:

env:
  LHCI_BUILD_CONTEXT__CURRENT_HASH: ${{ github.event.pull_request.head.sha || github.sha }}

I think it comes down to how you are fetching and checking out the code in your workflow. Assuming you are using actions/checkout@v3, there is a potential gotcha here depending on what value the action uses for fetch-depth. By default, this value is 1. This will initialize the repository and pull in a single commit, which will be the sha of a merge commit between the base and head branches.

In GitHub Actions environments, lhci will determine the current hash in one of two ways: the value from LHCI_BUILD_CONTEXT__CURRENT_HASH if it is set, or by running git rev-list --no-merges -n1 HEAD. If you're not currently using my suggested workaround above, then you're going to get the value from git rev-list --no-merges -n1 HEAD.

Assuming you used the default fetch-depth value of 1 in the actions/checkout action, then the Git repository in your runner workspace will have exactly one commit in its history. git rev-list --no-merges -n1 HEAD will return the value of this commit's sha, even though that sha is of a merge commit because that commit, within the context of the workspace repository, has no parents.

If on the other hand you have a fetch-depth of 0 set, then you will get the whole history behind the merge commit, and it will have two parents: the commit of the base, and the commit of the head branch. In this instance, git rev-list --no-merges -n1 HEAD will return the commit hash of the head branch.

This commit hash is sent off to the the Lighthouse CI's GitHub app endpoint, and at this point we don't know what it is doing behind closed doors in determining how it is attempting to add the status check result to the pull request. We can infer from the "if all else fails" Git command of git rev-list --no-merges -n1 HEAD that they never intended to retrieve the SHA of a merge commit, they want the commit from the actual head branch. So, there is probably some bug on the Lighthouse CI GitHub app side of things that is not properly handling the scenario where exactly one commit is present in the history, and the sha of that commit is actually a merge commit.

That's my best guess as to what might be happening.

To see how lhci determines what the current hash:

https://github.com/GoogleChrome/lighthouse-ci/blob/main/packages/utils/src/build-context.js#L58-L85.

Here is what lhci does to run the status check:

https://github.com/GoogleChrome/lighthouse-ci/blob/main/packages/cli/src/upload/upload.js#L227-L307

Status check post function:

https://github.com/GoogleChrome/lighthouse-ci/blob/main/packages/cli/src/upload/upload.js#L143-L180