Open zi-gae opened 1 year ago
Seeing the same issue, also unable to access GitHub CI App properties.
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
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
PR Action comment
code is here.