Skip to content
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

sightglass-next: implement sightglass-server #93

Open
abrown opened this issue Mar 5, 2021 · 2 comments
Open

sightglass-next: implement sightglass-server #93

abrown opened this issue Mar 5, 2021 · 2 comments
Assignees

Comments

@abrown
Copy link
Collaborator

abrown commented Mar 5, 2021

In order to report performance results based on PRs, we talked about implementing an HTTP server (e.g. in crates/server) that would:

  • listen for incoming POST requests that contain JSON with the PR URL, commit SHA, etc. necessary for doing a "master vs PR" comparison
  • to avoid DoS, verify that the request is an authorized one (not exactly sure how to do this but the GitHub action will need some form of token)
  • kick off some benchmark running, like sightglass-cli benchmark ... but we could call the same APIs from inside the web service
  • upon success, push a Markdown table of the significant performance differences as a comment to the GitHub PR (implies that sightglass-server has a GitHub token, like one from bytecodealliance-highfive)
  • upon failure, push the error message as a comment to the GitHub PR (implies that we maintain error logs somewhere)

There is a lot more to be done here but that should be a workable start.

@jlb6740
Copy link
Collaborator

jlb6740 commented Mar 17, 2021

@abrown thanks for posting this. Finally getting to here and wanted to acknowledge this. Before doing this particular issue will first refactor work on the original sightglass. That hopefully won't take long.

@fitzgen
Copy link
Member

fitzgen commented Jun 9, 2021

kick off some benchmark running, like sightglass-cli benchmark ... but we could call the same APIs from inside the web service

I think we actually do want to spawn the CLI in a subprocess because all of the random ordering of processes/iterations is inside the CLI crate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants