-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
report: save to trace-cafe storage for auth-less permalinks #15620
base: main
Are you sure you want to change the base?
Conversation
@@ -2,7 +2,7 @@ | |||
"extends": "../tsconfig-base.json", | |||
"compilerOptions": { | |||
// Limit to base JS and DOM defs. | |||
"lib": ["es2020", "dom", "dom.iterable"], | |||
"lib": ["es2021", "dom", "dom.iterable"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needed for string.replaceAll()
Nice, this is much simpler. The strings say "permalink", but you mentioned a "365 day TTL". Is this PR currently trading perm-storage for 365 TTL? That seems long enough, but just want to make it clear if that is what's gonna change. If so, calling it "permalink" is not right. |
return id; | ||
const updatedUrl = new URL(LighthouseReportViewer.APP_URL); | ||
updatedUrl.searchParams.append('id', id); | ||
history.pushState({}, '', updatedUrl.href); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wdyt of going even simpler and just making this the jsonurl=
to firebase storage URL (then we can drop special handling of ?id
. reasons not to:
- we like the shorter url
- the bucket or path may change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i like the short url. and i'm excited about https://googlechrome.github.io/lighthouse-ci/difftool/?left=<id>&right=<id>
Right now with full urls this gets super long and ugggly
* @param {LH.Result|LH.FlowResult} jsonFile The gist file body. | ||
* @return {Promise<string>} id of the created gist. | ||
*/ | ||
async createGist(jsonFile) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥
yes. :)
this is fair. i realize now i avoided that term on trace.cafe (for that reason) and went with "shareable URL" Since we're bikeshedding words.. i feel iffy on "Get".. Do you think |
Upload/Get doesn't make much difference to me. You can't get a url without putting your data somewhere. shrug. But, on the point of "your data", with gist you could always delete your data. afaik you can't with trace.cafe. should that be a requirement before we can use trace cafe? butttt now we need auth again, and you'd need to build out login/deleting data, and .... ugh. So maybe an explicit prompt when you click "get shareable url" that says "your data will be uploaded to trace.cafe and shareable only via this URL for 365 days. Continue?". With that explicit permissions maybe we can curtail needing to provide a way to delete something |
ID looks like |
yeah that's where i was coming at it from... i don't like dealing with the permission prompt and storing that preference etc... so... I just renamed it to 'Upload for Shareable URL' to make that action obvious and explicit. |
The user experience seems to be better all around for this (uploading from DevTools is pretty amazing), but as a relatively heavy user of gist uploads, I'll put in a plea for retaining the gist functionality. The biggest thing is probably links working for longer than a year or whatever the TTL ends up settling on. I don't go back through my gists looking for old memories, but I do go back through links from old bugs (year old bugs don't seem as old as they used to), docs, etc and it's definitely nicer when they're still working. In terms of "your data", I also just generally like the fact that I know where my gists are and how to manage them for things that are meant to be a record of something, vs an ephemeral "hey take a look at this thing" in chat or wherever that trace.cafe is great for. Since it's an option only visible from the viewer drop down, seems like it could continue living there without adding much confusion about which option to use for getting a shareable link. |
Why not file://? Seems like a useful way to share reports generated via CLI. |
I agree the cli generated reports would really benefit from this feature :) |
@brendankenny want gist uploading functionality? cuz i was gonna keep around downloading. also in that world, you can still upload gists manually at gist.github. wdyt? |
Yeah, sorry, I meant gist uploading.
Well, yes, similar to manually uploading at https://trace.cafe/ :P Having a button makes it very nice :) |
: null; | ||
}) | ||
.then(() => fetch(jsonurl)) | ||
} else if (jsonurl ?? cafeid) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this is the effective condition so let's make it explicit
} else if (jsonurl ?? cafeid) { | |
} else if (jsonurl || cafeid) { |
finalDisplayedUrl: Util.getFinalDisplayedUrl(reportJson), | ||
fetchTime: reportJson.fetchTime, | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this filename
logic move inside uploadLhrToTraceCafe
?
The save as gist workflow has always been complicated.
anyway.. this is a single
fetch()
POST to upload and no auth needed. 💅a few moments later:
why https://trace.cafe? I'm using a bucket within the trace-cafe project only because there we already figured out the protected permissions and 365 day TTL stuff. the user doesn't see trace cafe.. heck the URL under the hood is something like
https://firebasestorage.googleapis.com/v0/b/tum-lhrs/o?name=lhrs%2Fl<ID>
.. but anyway..This PR drops the upload-as-gist functionality. However apparently we still need firebase/github auth to download gists.. (We really shouldn't, but the PR was getting big already).
Followups: