Please describe the desired behavior.
Currently, we don't have any ci tool used for performance and accessibility monitoring. Lighthouse ci is google based opensource tool that allows us to check prs for performance and accessibility.
https://github.com/GoogleChrome/lighthouse-ci
https://github.com/GoogleChrome/lighthouse-ci/blob/master/docs/getting-started.md#modifications-for-sites-with-a-custom-server
@icarito @jywarren pulling the discussion from gitter here :sweat_smile:
From #publiclab :
My understanding when looking at that link is that they want to start the server locally at their site, not at our server, it can be done, e.g. with docker-compose like we do in our own staging.
Following the instructions, it appears a lighthouserc.js needs to exist and have a start command like docker-compose up
with the right environment variables available.
One more concern is that the url option is an array of all urls that can be added to be investigated ... so do we add all the possible urls here in publiclab or how do we dynamically maintain what urls have been changed in a pull request
https://github.com/GoogleChrome/lighthouse-ci/blob/master/docs/configuration.md#url
Just adding here @jywarren @icarito the gitpod thing once setup can easily allow lighthouse to directly run on the git pod generated deploy url :tada: #8152
Hey @jywarren @icarito what do you think should we proceed with this? :sweat_smile: Thanks :v:
Hey @jywarren @icarito @cesswairimu @sagarpreet-chadha should we add this Lighthouse check on every pull request? Thanks :v:
Hey @Tlazypanda , yes it will be very helpful if we get this metric report on each PR/commit.
We will need a nodejs server and a DB to store these all reports to get an in depth analysis.
@icarito mentioned we already have docker
setup in stage, so we can run lighthouse server container also maybe there?
However if we donot need historical data, we can easily set this up in few steps, right? Mainly make the lighthousrc.js file, add travil.yml and add github checks.
I think the report will be pushed to some temp storage in this case, but that should be alright.
Yes @sagarpreet-chadha thanks for the review :v: should I move ahead with it then? The temp storage will delete the report in 7 days :sweat_smile:
So should I go ahead for the normal one for now or the one preserving history? cc @jywarren
Hey @Tlazypanda , let's integrate the normal one.
It is good to have historical data but I am not sure how useful it will be given we will have to setup resources especially for this. Any ways you go ahead with the normal steps, meanwhile I will pitch this to @icarito @jywarren @ebarry
Thanks 馃槃
I am so sorry I missed this. Please forgive!
This sounds great and gitpod does make it much easier and cheaper. I agree let's start without history. We can see what is preserved and if we see a use case for preserving once we start to use the feature.
I wonder if there's a way to either indicate or simulate that the users table is huge, as that is the source of a lot of slowness. By contrast the nodes table isn't that big.
Thanks @Tlazypanda!!!!
Hey @jywarren @sagarpreet-chadha @icarito Thanks so much for the go-ahead!! :heart:
Actually was navigating through some issues first since right now on gitpod for getting the pr specific url first we need to login with github so in my Gh action script for lighthouse how do I fetch this dynamically generated link available only after login? :sweat_smile:
The inital link looks like https://gitpod.io/#https://github.com/publiclab/plots2/pull/8349
which then after login changes to a different link :sweat_smile:
One more concern is that the url option is an array of all urls that can be added to be investigated ... so do we add all the possible urls here in publiclab or how do we dynamically maintain what urls have been changed in a pull request
https://github.com/GoogleChrome/lighthouse-ci/blob/master/docs/configuration.md#url
Also this should we include all possible urls? :sweat_smile: what about the ones that are locked
Let's start with some of the (public) highest traffic and worst performing ones, as per skylight.io, what do you think? Public routes will have more traffic anyways, and it's an easier starting point.
As to your Q about the URL - can you share your script so far? I bet there's a way to find the exact URL after boot in the GitPod docs. But I'm not yet following where you want to use that - can you not hit a localhost
type path from within GitPod?
Thank you!!!
Most helpful comment
Hey @Tlazypanda , let's integrate the normal one.
It is good to have historical data but I am not sure how useful it will be given we will have to setup resources especially for this. Any ways you go ahead with the normal steps, meanwhile I will pitch this to @icarito @jywarren @ebarry
Thanks 馃槃