-
Notifications
You must be signed in to change notification settings - Fork 90
Add enhanced GitHub Actions raw logs viewer #2076
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
base: master
Are you sure you want to change the base?
Conversation
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.
This is a really wonderful idea ❤️ And I can't wait to use it! I can take care of the RLA integration once/if this is merged.
Ok(res) | ||
} | ||
|
||
async fn process_logs( |
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.
Could we add some cache for this in Context
? Maybe a LRU hashmap or something like that? The logs can be large and we probably don't want to spam the GH API when the page is refreshed or a couple of people go visit a link when a job fails.
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 though of it, but given some of the size of the logs (some of them go 3-4 Mb each) I'm worried we'll have a huge cache miss due to the limited number of logs we'll be able to cache.
I also don't know how much we can safely cache, I don't how much RAM the triagebot machine has left. Or maybe we'll want to have the cache on disk?
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 wouldn't go for a disk cache. I think that even storing a Vec of ~10-100 last results would be enough. Logs are usually accessed only for a brief period of time after CI fails, when a bunch of people may get notified and they go check the logs. After a few days, people usually don't care about the log anymore. So remembering the last N logs to have a history of at least a few hours would help to avoid needless API requests, IMO.
Not sure about RAM size, but storing e.g. 20 results should hopefully be fine. @Mark-Simulacrum should know the machine specs, I think.
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.
Okay, added a small cache of 50Mb for the raw logs in RAM.
We could also just host the ansiup file ourselves through triagebot, it's relativey small (~14 KiB). |
32638f3
to
3242c4f
Compare
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.
Impl looks good, but I'd like to hear from Mark or someone else from t-infra about potential security concerns.
This PR adds an enhanced (as in colored) GitHub Actions raw logs viewer.
This is useful for us as Github Actions logs viewer is just unusable in rust-lang/rust given the size of our logs (it loads indefinitely) and the raw logs are full of ANSI sequence cluttering the output.
This works by adding a new endpoint
/gha-logs/:owner/:repo/:log-id
(restricted to team repos) that fetch from GitHub REST api the raw logs, embeds it directly in the HTML which are then processed by theansi_up
javascript library (loaded from jsdelivr.com CDN).To prevent XSS injection (or just bugs in
ansi_up
) I added theContent-Security-Policy
header with restriction inscript-src
. I also tried adding integrity foransi_up
but jsdelivr doesn't guaranteed the same content for minified libraries.After merging, we should probably adjust rust-log-analyzer to link to this new endpoint instead of to GitHub, so people can use directly.
cc @Mark-Simulacrum