Taichi: Improve format server UI

[yuanming-hu]

Concisely describe the proposed feature

Currently, the format server has a rather minimal UI. It's very easy for people to misclick:

Describe the solution you'd like (if any)

Two ways:

• (A) Interface the web API with GitHub action so that users can format their PR by simply clicking a button
• (B) Improve the web UI to avoid misclicking (say pop up a confirmation msgbox)

The first way is more systematic yet also more challenging to implement. The second way can be a temporary solution.

Additional comments
You can start the server locally by python3 misc/format_server.py. Thanks!

[archibate]

Cool! To disable misclick in plan B, you want to:

1. Seek history to find which PR does user come from.
2. Specify GET argument in PR template [Click to format].

[yuanming-hu]

Cool! To disable misclick in plan B, you want to:

1. Seek history to find which PR does user come from.
2. Specify GET argument in PR template [Click to format].

Yeah, this sounds reasonable. However, I'm not sure if it is possible to get the users's history and github account.

(I'm not a web expert...)

[archibate]

I'm thinking about [Click to format] instead of [Click here for the format server], only PR author and reviewers can click it, do you know if api.github.com provides user infomation access? Basically user name, user permissions to our repo.

[yuanming-hu]

2. Specify GET argument in PR template [Click to format].

Yeah, I tried this one but failed to find something like ${GITHUB_PR_ID}...

I'm thinking about [Click to format] instead of [Click here for the format server], only PR author and reviewers can click it, do you know if api.github.com provides user information access? Basically user name, user permissions to our repo.

I have no idea about that, sorry...

[archibate]

Found https://developer.github.com/v3/users/#example-1

[archibate]

According to https://www.w3school.com.cn/jsref/dom_obj_history.asp:

History 对象最初设计来表示窗口的浏览历史。但出于隐私方面的原因，History 对象不再允许脚本访问已经访问过的实际 URL。唯一保持使用的功能只有 back()、forward() 和 go() 方法。

Plan 1 dead.

May be we can trigger format server when commit message contains [format] using wget http://kun.csail.mit.edu:31415/%APPVEYOR_PULL_REQUEST_NUMBER%?

[archibate]

test content, no reply:
test link

[rexwangcc]

Sorry I come to this party late. I came across this issue from #620 and #677 (Set up Cpplint Set up pylint).

With a simple test it seems both (A) and (B) are feasible, and I already see some progress on (B). But I also want to bring up a potential solution (C) which is a one step further variant of (A): hand off the actual formatting and committing job to Github Actions, instead of just sending a request to the format server.

Comparison:
(A) (B) both put some traffic/maintaincen presure on the centralized format server but give developers more flexibility, while the logs are not easily available to the developers so extra back and forth might need to happen if something goes wrong.

(C) will lift up the stress on the server and natually distribute the work across Github Actions runners, which, in the free tier, provides up to 6 hour free time. Problem is that the runner VM (docker container)s are one-off, so without proper cache set up, there will be a lot of overhead each time a format job gets executed by the runners, this depends on how easily can a ti.format be setup in a fresh VM from scratch.

I'm not leaning towards either but the way the current format server's set up really triggered my worry (I almost mis-clicked others' PR while looking through it...), and I believe it's not just a UX design issue but can become real problems from the security and turnaround perspectives as it gets more attention...

[rexwangcc]

By the way, if I could get some help from mantainers who have access to the diligent @taichi-gardener to create a Github OAuth application, and discuss about how/where to safely store the OAuth client ID/secret, I could make a PR to implement (B) soon. (If it goes well hopefully it could also address issue #620 by setting up OAuth for the server and authenticate every request (if we still want to keep the server up and running in the future).)

(The logic will be as simple as, redirect users who go to the MIT server to a Github OAuth page, once user authorize it, it will redirect the user back to the actual formatter page and only show that user's PR by filtering all open PRs by the user github id )

[yuanming-hu]

Sorry I come to this party late.

Welcome!

A few things to check out:

• Related (new) issue: https://github.com/taichi-dev/taichi/issues/956
• Related (new) PR by @archibate: https://github.com/taichi-dev/taichi/pull/957

Actually, I believe many of the current developers are leaning towards (C) now.

What we find is that relying on the reviewers to always click the format server is kinds of unrealistic. So we are switching to a GitHub action. The development is in progress by @archibate.

After the GitHub action is functioning, I believe the ad-hoc format server can be abandoned.

The @taichi-gardener account is managed by me - if you need access to this account, please feel free to let me know :-)

[rexwangcc]

Thanks for the prompt 🚀 reply! I will take a look at the issues/PRs above.

It seems #957 is going down the path A, but once the first draft is setup it will be pretty easy to iterate on it!

The @taichi-gardener account is managed by me - if you need access to this account, please feel free to let me know :-)

Thanks, I think we only need to bother the gardener if we want to go with path B and add OAuth and Authentication on the server. Most of the development work before the final step could be done with my testing accounts.

[yuanming-hu]

It seems #957 is going down the path A, but once the first draft is setup it will be pretty easy to iterate on it!

Right, I guess as time goes by we will end up with something similar to https://github.com/halide/Halide/blob/master/.github/workflows/presubmit.yml

[rexwangcc]

Yup! (the only difference might be we are talking about both lint and format here but that one looks more like just lint checks, which is relatively faster)

[rexwangcc]

It turns out to be really easy to test path B, like: link

Note the code=xxx in the redirected server URI, which then can be used by the server to trade in a Bearer token from Github and filter out PRs that not belong to the user.

[yuanming-hu]

Looks really cool! Thanks for setting up GitHub OAuth. I believe it will be useful for future applications.

I personally think, however, it is better to directly proceed to (C) and abandon the format server (which I wrote a couple of months ago and I believe it has contributed enough...) For mechanical jobs like enforcing formats, we should probably trust machines (GitHub Actions) other than humans.

[rexwangcc]

Yeah, I strongly agree if that's the concensus here! Having de-centralized CI runners will bring a lot of convenience for external contributors.