[Feature] A whole new feature called FastPR

[frank-zsy]

Description

As the analysis in 2023 China Open Source Report, openEuler embedded a cloud IDE in their website to improve the experience for developers who want to contribute to their docs.

The feature is really helpful for open source projects to attract developers and users of their projects to contribute the docs and fix bugs in the docs for community. And I think HyperCRX is a good form to implement this feature for projects' websites.

As shown in the video below, we can add a Markdown editor for all the docs page and after user closes the editor, HyperCRX can open a new PR in the corresponding repo for the user if GitHub token is set.

normal.video.mp4

[wangyantong2000]

Next, I will follow up on this issue.

[frank-zsy]

@wangyantong2000 Thanks. I think there are several things we need to take care about:

• First we should refactor the extension's load mechanism to support all website rather than only GitHub, and all the GitHub feature right now should only be loaded in GitHub. This could be an independent feature and a new issue.
• Then we need to design how to config the load setting of this feature, that I think is:
  • The domain name of the docs website, like open-digger.cn which is the docs website of OpenDigger.
  • The corresponding platform, repository and development branch of the website, like github, X-lab2017/open-digger-website and master.
  • The supported pages and the rules to get the raw markdown file. It is tricky here because the rule could be complex and we should decide that does we support script here or just use regex here. I prefer the script but it requires js config file rather than json format.
  • And the config file above should not be inside the extension release and should be fetched from remote URL and update regularly. Which makes it possible to add new config dynamically without update the extension it self.
• Then it is the procedure to raise PR directly from the website page and we should also add a confirm input dialog after the editor is closed which allows users to modify the PR title and body.

This feature requires lots of complex changes and really challenging, thanks to @wangyantong2000 again.

[wangyantong2000]

iShot_2024-10-20_21.01.33.mp4

This is the initial demonstration of the feature, which is planned to be improved in three steps:

1. Determine which features are compatible with the GitHub platform and which features are compatible with other websites, and develop corresponding loading rules.[Feature] Refactoring of function loading rules to adapt to the purpose of multiple websites #891
2. Improvement of FastPR function process (construction of corresponding functions between document webpage URL and repository webpage URL, improvement of automatic PR process, and front-end display components).
3. Perhaps we can take this opportunity to build a set of components for notification prompts. For example, in FastPR, some Github API requests are made to indicate success or failure or the reason for which step failed. Perhaps it can also be used in other functional areas.

[wangyantong2000]

If a new fork repository is created and named fastpr-owner-repo. Do we still need to determine whether the user has write permission in the repository, that is, whether all types of users need to create a fastpr-owner-repo repository. And I feel that forking a repository only requires forking the default branch of the original repository, which is default-branch-only=true. @frank-zsy

[wangyantong2000]

A new discovery is that if a repository has already been forked, calling the GitHub API to create a fork does not create a new fork with the name we specified, but instead returns information from the previous fork.
So this way, the process can be simplified. First, check if you have permission, and if not, directly call the GitHub API for creating forks. If there was no previous fork, return the information of the fork created this time, otherwise return the information of the previous fork.

[wangyantong2000]

In the attempt on the Gitee platform, the request encountered cross domain issues.

[frank-zsy]

If a new fork repository is created and named fastpr-owner-repo. Do we still need to determine whether the user has write permission in the repository, that is, whether all types of users need to create a fastpr-owner-repo repository. And I feel that forking a repository only requires forking the default branch of the original repository, which is default-branch-only=true. @frank-zsy

Yes, actually we can just simplify the process and fork the repo for all users and no need to push to a branch in upstream repo.

In the attempt on the Gitee platform, the request encountered cross domain issues.

I searched the Internet and seems that Gitee does not support similar thing like raw.githubcontent, if we have a Gitee token, we can use v5 API to get the file content https://gitee.com/api/v5/swagger#/getV5ReposOwnerRepoContents(Path)

[wangyantong2000]

The first generation of FastPR functionality has been developed. A tutorial on using this feature will be written in the future. And continuously adjust iterations based on user feedback.