-
Notifications
You must be signed in to change notification settings - Fork 647
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is getAncestorHash in healthcheck relevent as implemented yet ? #485
Comments
Thanks for filing @jfmou! You're right we should be threading through the baseBranch into the getAncestorHash function instead of hardcoding lighthouse-ci/packages/utils/src/build-context.js Lines 319 to 329 in 0449e6e
We'll need to make the same project API request to fetch the |
Well glad to help ! Thanks for your feedback. Love this product 🥇 |
patrickhulce
added a commit
that referenced
this issue
Nov 10, 2020
patrickhulce
added a commit
that referenced
this issue
Nov 10, 2020
patrickhulce
added a commit
that referenced
this issue
Nov 10, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm having little trouble understanding the point of this check which fails on my pipeline most of the time.
We do "merge with commit" our feature branches into develop then develop into master.
The base branch for our repo in our lhci server is develop.
When auditing our feature branches or freshly merged develop with lhci the check systematicaly fails since
baseBranch
isn't set, resulting ingetAncestorHashForBranch
using master as default branch which is not present as an ancestor of develop (nor the feature branches).Uploads never failed that said, since the implementation seems more robust, requesting server data for baseBranch :
lighthouse-ci/packages/cli/src/upload/upload.js
Lines 399 to 409 in 0c5db08
It doesn't fail the job and is only a warning, but it triggers me on the check itself and what to expect about it, since it always assume master is an ancestor.
I guess It would never failed if we did used fast forward merge strategy right ? Making master and develop always an ancestor of the feature branch.
I may be missing something here, but when i audit our master it succeeds, making me think I have a good lead.
Any ideas ?
The text was updated successfully, but these errors were encountered: