[Bug] Widgets do not show at GreptimeDB repo

[tisonkun]

Version

No response

Current Behavior

https://github.com/greptimeteam/greptimedb

I cannot see the OpenRank widgets as well as Perceptor.

Expected Behavior

I'd like to check the data for this repo.

Environment

- OS: MacOS Ventura M1
- Browser: Chrome Version 120.0.6099.234 (Official Build) (arm64)

Any additional comments?

No response

[frank-zsy]

@tisonkun The data URL is strictly identical with the GitHub repo name and it is case sensitive. So you should visit this URL: https://github.com/GreptimeTeam/greptimedb and the data will show up. We should check if there is another way to get the repo name from page meta data rather than the URL path so we can know the actually name of the repo.

[tisonkun]

SGTM. How can this plugin currently resolve the name? GitHub treats repo name case insensitive though.

[frank-zsy]

Right now, Hypercrx parses the window.location to get the repo name, I found there are some places in the web page to find out the real repo name, but we can not ensure to get the name since GitHub change the page content constantly while refactoring the website.

[tisonkun]

If you can access GitHub API, here are two methods you can resolve the name with "greptimeteam/greptimedb" to the proper fullname:

With REST API:

gh api -H "Accept: application/vnd.github.VERSION.sha" repos/greptimeteam/greptimedb | jq -r '.full_name'

You can rewrite this command with the JS API trivially.

With GraphQL API:

query {
  repository(owner: "greptimeteam", name: "greptimedb", followRenames: true) {
    nameWithOwner
  }
}

[frank-zsy]

Yes, this is a good method, although GitHub API call without token is limited by IP so it will be quite easy to hit the rate limit. If we support login to GitHub from the extension, we can use API calls to get the data and even more other interactions with GitHub.

[tisonkun]

I'm using GitHub Issue Link Status plugin also which should apply the tech you mention. You can check its code for how to do it.

[frank-zsy]

I installed the extension and it requires a GitHub token input manually on installation to call the API, actually we also provide the functionality before but removed in recent versions. I think we should add it back for further features.

[wangyantong2000]

At present, HyperCRX has added the function of obtaining GithubToken, and we can consider how to better solve this issue.

[wangyantong2000]

At present, some information about repositories and developers, such as names, is obtained by parsing URLs. And some repositories and developers' capitalization confusion issues can render our functionality ineffective. We have added a place to fill in GitHub tokens, and we can explore how to better obtain relevant information through GitHub API. @Xsy41, can you try how to better solve this problem？

[Xsy41]

We can parse the warehouse name using the <header> tag.

[wangyantong2000]

We can parse the warehouse name using the <header> tag.

It's not just about solving this problem. Similar to the confusion between uppercase and lowercase usernames, there will be similar issues. When refactoring GitHub's page structure, it is also necessary to parse the page again. By encapsulating some Github API functions to handle the retrieval of repository and user related information. Will there be no need to consider page refactoring and be able to obtain more information, not just the name of the repository?

[wangyantong2000]

The feature of storing and using GitHub tokens on the option page previously done by others is not available, and you will find that you cannot obtain GitHub tokens already stored on other pages at all. I have already made the necessary changes to this section and will upload it as soon as possible.

[wangyantong2000]

We can parse the warehouse name using the <header> tag.

Of course, it can also be considered that users may not necessarily know to fill in the GitHub token. And there are difficulties in generating GitHub token for users. So can we consider obtaining page elements when we cannot obtain the token filled in by the user? Or a prompt to fill in the token? My idea is to create a packaged method that utilizes the GitHub API, in addition to the existing methods for obtaining information in the current project. I don't know if it's necessary.

[Xsy41]

At present, the initial fix is to add the method of retrieving the warehouse name by the page element, but also retain the method of retrieving the warehouse name by the url, ensuring that even if the warehouse name obtained by the two ways has a case inconsistency, the result of page element resolution will be preferentially used. When a github page is refactored, the repository name can still be retrieved using the url.