roadiehq/backstage-plugin-github-insights

A Backstage Plugin for Top Contributors, Languages, Releases etc.

backstage-plugin-github-insights's Issues

Unable to fetch avatars

Hello!

This might be more of a question than an issue, but when i open my personal settings page i am met with an anonymous icon, despite being signed into GHE. Is this something i need to configure on my GHE instance or is this something we can resolve from the plugins side?

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://ghe.*********.com/login?return_to=https%3A%2F%2Fghe.************.com%2Favatars%2Fu%2F399%3F with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.

Browser: Chrome, version 86.0.4240.193 (Official Build) (64-bit)
GHE Auth: Secured with SAML2
Backstage Auth: OAuth2 through GHE
Backstage is running HTTP and not HTTPS.
Plugin version: 0.2.12

Language color button isn't visible for HCL code

Expected Behavior

• A colored circle appears next to each identified language in the Language widget.
• The associated color is represented in the stacked horizontal bar chart representing it's percentage.

Current Behavior

One of my languages seems to have no color circle, or it's being flipped somehow based on the theme.

Here's what's actually in my real GitHub repo:

And the screen shot of the widget in both light and dark theme. In this screen shot, the HCL code (i.e., Terraform), seems like it has no circle, and it's also missing from the horizontal stacked bar chart:

Here's another repo which has the same issue, ALSO for HCL. Not sure if it's HCL which is the issue, or the fact that it's the third one, or not?

Possible Solution

Steps to Reproduce

1. Set a github repo annotation in a catalog-info.yaml file
2. Load it into Backstage
3. View Language Widget

Context

Your Environment

• Plugin Version (version of this software e.g. v0.4.3): 0.2.16
• Backstage version (e.g. 0.1.1-alpha23): 0.4.2
• NodeJS Version (e.g. v12): 12.16.2
• Operating System and Version (e.g. Ubuntu 14.04): Windows 10 19091 WSL2 Ubuntu 18.04
• Browser Information (e.g. chrome 85): Microsoft Edge (Chrome engine)

EntityGithubInsightsContent consumes entity via props

To fully migrate to the composability API the entity page components need to consume the entity via context rather than props, i.e. via useEntity. The typical pattern is to make the entity prop optional and ignore it, allowing existing code to keep passing it while still supporting the new method.

CORB on contributors icons.

I'm getting CORB when opening the insights page. Is this something i need to configure locally, or in my GHE instance?
I can properly inspect the contributor and find links to GHE depicting the person. But the image is missing.

Version:
"@roadiehq/backstage-plugin-github-insights": "^0.2.15"

Chrome Error Message

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://ghe.************.com/login?return_to=https%3A%2F%2Fghe..************.com%2FMikael-Ostberg.png with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.

Related app-config.yaml

  cors:
    connect-src: ["'self'", 'http:', 'https:']
    img-src: ["'self'", "data:", "https://ghe.****************.com"]
    credentials: true
  csp:
    connect-src: ["'self'", 'http:', 'https:']

Bug: Repo with no languages throws error in the Language widget

Issue

I used an empty repo with just a README and a catalog-info.yaml as a test, and happened to cause the Languages Widget errors out:

Visual verification

Sure enough, when I visually look at the repo, it lacks a languages bar visible:

Versus another small repo with some real code stored into it:

API Verification

My new repo which is causing the error:

$ curl --user "myuser:mypat" https://github.company.com/api/v3/repos/myuser/brand-new-repo/languages
{

}

And a "good" one with code:

# expected
$ curl --user "myuser:mypat" https://github.company.com/api/v3/repos/myuser/repo-with-code/languages
{
  "Batchfile": 2313,
  "Shell": 380
}

Notes

To be fair this is likely an edge case, but at least means there may need to be an extra error check (and a test?) if some aspect of the GitHub API get repo languages call errors out:
https://docs.github.com/en/free-pro-team@latest/rest/reference/repos#list-repository-languages

To reproduce

1. Create a new repo
2. Create a very simple README.md
3. Add a catalog-info.yaml for the relevant repo
4. Register existing component with this catalog-info.yaml
5. View GitHub Insights plugin
6. See broken Languages widget

Relative links to Markdown files in Readme card is broken

Expected Behavior

Relative markdown links in the README.md to other .md files in the repo should work.

Current Behavior

Links are routing to the raw view in Github with the file extension stripped and replaced with a / causing the broken links

Possible Solution

Steps to Reproduce

1. Create a relative link to another markdown file in the repo in the README.md eg. ./packages/foo/CHANGELOG.md
2. Click on the link in the README card of the plugin
3. Link routes to https://github.com/my-org/mr-proj/raw/master/packages/foo/CHANGELOG/ instead of https://github.com/my-org/mr-proj/raw/master/packages/foo/CHANGELOG.md

Context

I believe this bug was introduced in 1018fd2 and is due to this regex replacement:

backstage-plugin-github-insights/src/components/Widgets/ReadMeCard/ReadMeCard.tsx

Lines 117 to 120 in c97cdba

	).replace(
	/\[([^\[\]]*)\]\((?!https?:\/\/)(.*?)(\.md)\)/gim,
	'[$1]($2/)'
	)}

I'm not sure its correct to assume that relative .md links will refer to an existing TechDocs page. Maybe this should be toggled via a plugin config?

Your Environment

• Plugin Version (version of this software e.g. v0.4.3): 1.0.0

Add GitHub "Release Title" to Releases Card

Feature Suggestion

The current Releases Card displays a list of versioned releases. It would be great to augment this list if the repo in question has defined release titles. This is the metadata above and beyond just the tag name,

For example, this sample card:

Could be really useful if this additional info was added to it:

Possible Implementation

Something like:

Release Title (v3.3.3)

With the entire thing linked to get to the release, as it is now. In addition, adding contextual data like if it's a pre-release, etc, might be super valuable! (the info that can be released to end users; not talking about DRAFT which is visible only to repo admins)

Context

Helps elevate any contexual release info a product team may be attempting to display for their releases.

Uptake the MarkdownContent component

We should use the MarkdownContent component to render the Readme once it's merged upstream.

Context

Pending #3157

catalog component readme doesn't include embedded images

[Originally posted as backstage/backstage/issues/4345]

This is a pretty minor nit, but the catalog/default/component/component-name pulls in the README.md but not
any referenced images that are pulled in, e.g. via ![alt-text](docs/media/CCbyncsa4.0.png "CC BY-NC-SA 4.0")

Expected Behavior

The "mini" README should render completely

Current Behavior

Image references are rendered as broken images:

Possible Solution

Steps to Reproduce

1. Add this component: https://github.com/columbia-it/django-jsonapi-training/blob/master/catalog-info-github.yaml
2. Go to http://localhost:3000/catalog/default/component/django-jsonapi-training

Context

Your Environment

• Plugin Version (version of this software e.g. v0.4.3): 0.2.16
• Backstage version (e.g. 0.1.1-alpha23): @backstage/catalog-client: 0.3.5
• NodeJS Version (e.g. v12): v12.20.1
• Operating System and Version (e.g. Ubuntu 14.04): MacOS Catalina 10.15.7 (19H114)
• Browser Information (e.g. chrome 85): Chrome 88

Explain the different widgets on the README

In #166, Adam explained that he didn't know about the Compliance Widget that this plugin exposes.

We should add a list of the different widgets that are available via this plugin to the README. Each should have a name, the class you have to import to use it, and a screenshot showing what you get if you use it.

Bad Credentials error when used with GitHub Enterprise

From Discord (link to message):

GHE instances have two formats: https://api.host.com/ or https://host.com/api/v3. My firm uses the latter. I've played around with lots of permutations of host, base URL, etc, and no matter what the GitHub Insights plugin just always shows Bad Credentials but I can't seem to trigger any additional debugging to find out why. (even w/ LOG_LEVEL=debug as env var) GHE interface says my PAT has been used, but that may only be because it works in integrations for loading up catalog YAMLs. Welcome any, achem, insights!

catalog:
  processors:
    githubOrg:
      providers:
        - target: https://myhost.mycompany.com
          apiBaseUrl: https://myhost.mycompany.com/api/v3
          token: myPATtoken
scaffolder:
  github:
    host: https://myhost.mycompany.com/api/v3
    token: myPATtoken
    visibility: public

Links at bottom of widgets broken to GHE instance

I use a GHE custom instance with this plugin. I realized that all of the links at the bottom of the widgets are actually broken, all with a format of:

http://localhost:3000/mycustomgheinstance.company.com/aharvey/backstage-sample-component/graphs/contributors
http://localhost:3000/mycustomgheinstance.company.com/aharvey/backstage-sample-component/blob/master/README.md

The code which is roughly common to the various widgets to build these URLs is here:

backstage-plugin-github-insights/src/components/Widgets/ContributorsCard/ContributorsCard.tsx

Lines 56 to 63 in 1b13df1

	<InfoCard
	title="Contributors"
	deepLink={{
	link: `//${hostname}/${owner}/${repo}/graphs/contributors`,
	title: 'People',
	onClick: e => {
	e.preventDefault();
	window.open(`//${hostname}/${owner}/${repo}/graphs/contributors`);

Which essentially seems to be suffixing my proper host URL and building a valid path, but defined without the protocol, which seems to thus be suffixing all of it to my local Backstage instance (running on my laptop).

It's an interesting challenge, as in the config integrations key, the apiBaseUrl includes both protocol + host, while the host key contains ONLY the host. Only the processors key contains a provider target with the full protocol + host.

For now, I guess the code quickfix could assume I'm on https but I suppose there could be (very !) rare edge cases where that's not the case. :)

Compliance Card: Visual alignment in protected branches row off with large number of branches

Expected Behavior

In the Compliance Widget, when there are a large number of protected branches, the visual formatting remains consistent.

Current Behavior

The formatting looks a little bit off. In particular, there seems to be additional whitespace in the value column above the very first branch name (develop in this case).

Possible Solution

Test with a repo with a larger number of protected branches and play around with the alignment in the table?

Steps to Reproduce

1. Add a good number of protected branches to a repo.
2. View it with the compliance card.

I don't know a good number, but in my example screen shot, one of my teams has a repo with thirty (30) protected branches, so all 30 show up in the column and that's where the whitespace seems to show up on the top.

Context

Your Environment

• Plugin Version (version of this software e.g. v0.4.3): v1.1.1
• Backstage version (e.g. 0.1.1-alpha23): release-2021-04-21
• NodeJS Version (e.g. v12): v14.16.1
• Operating System and Version (e.g. Ubuntu 14.04): Mac OS Catalina
• Browser Information (e.g. chrome 85): Safari

Link in Read Me Card is Broken

The Github Insights README says:

By default the plugin will use the annotation github.com/project-slug and get the root README.md

but then hardcodes README.MD for the URL path in the Read me card. Causing the Read me link to go to a Github 404 page.

Expected Behavior

Clicking the "Read me ->" without the annotation github.com/project-readme-path, gets the root README.md from the repository.

Current Behavior

Clicking the "Read me ->" without the annotation github.com/project-slug, gets the root README.MD from the repository. This 404s since the file in our repo is README.md and not README.MD.

Possible Solution

Update https://github.com/RoadieHQ/backstage-plugin-github-insights/blob/main/src/components/Widgets/ReadMeCard/ReadMeCard.tsx#L69 to be README.md

Or

Use the result from hitting Githubs API for /readme to get the repo's readme URL.

Steps to Reproduce

Unfortunately I can't link to our instance.

1. In Backstage catalog, go to a component that has the Github insights plugin and whose repo's readme file name is README.md
2. In the Read me Card, click "Read me ->".

Context

The read me link is broken for our repos because we name our Github readme's as README.md

Your Environment

We use Github Enterprise

• Plugin Version (version of this software e.g. v0.4.3): ^0.2.7
• Backstage version (e.g. 0.1.1-alpha23): release-2021-01-14
• NodeJS Version (e.g. v12): v14
• Operating System and Version (e.g. Ubuntu 14.04): macOS Mojave
• Browser Information (e.g. chrome 85): Chrome 88

Broken readme link

When i click the readme-link that directs me to our resident GitHub Enterprise repo readme i end up at a malformed URL without the colon (:) of the protocol https//ghe.some.company.com.

If you click here:

Link showing in the bottom of the browser before click:

Link showing in the omnibar after following the link:

Expected Behavior

I expect to end up at my example-docker-service readme.

Current Behavior

I end up at a malformed URL

Possible Solution

Figure out where the colon is removed in the backstage redirect link.

Steps to Reproduce

1. Open a component with a github readme
2. follow the readme link

Context

Not a particularly important feature to me so i guess it doesn't bug too many. But still, links should work! :)
The GHE is protected with SAML2 authentication if that may matter.
Originally created the issue in the backstage project here: backstage/backstage#3312

Your Environment

• NodeJS Version (v12): v12.19.0
• Operating System and Version (e.g. Ubuntu 14.04): RHEL7 for host os, application running in docker container packaged by vanilla Dockerfiles from the backstage project.
• Browser Information: Chrome, Version 86.0.4240.193 (Official Build) (64-bit)

github.com/project-slug annotation not being read

github.com/project-slug annotation is not being recognized.

Expected Behavior

github.com/project-slug annotation is read and Code Insights plugin utilizes it to display it's content.

Current Behavior

Receive a screen stating to add the annotation to the Component:

Steps to Reproduce

1. Follow the steps outlined in the README to setup the plugin.
2. Add github.com/project-slug annotation to Component
   
3. Reboot application

Context

• Swapped my-org/my-project in for real project handle in the screenshot.

Your Environment

• Plugin Version (version of this software e.g. v0.4.3): v1.1.9
• Backstage version (e.g. 0.1.1-alpha23): v0.7.9
• NodeJS Version (e.g. v12): v12.19.0
• Operating System and Version (e.g. Ubuntu 14.04): Ubuntu 20.04
• Browser Information (e.g. chrome 85): firefox 88.0.1

GitHub Enterprise Contributor popups don't work: Fetching Failed on avatar icons

When I view the Insights Panel, I successfully have the contributors panel, languages, and so on. In my Backstage config, I use both GitHub Enterprise OAuth for authentication, but also have a GHE Token defined, as evidenced by the fact that the plugin can pull this data in the first place.

However, when I hover over the image icons for my contributors, I get a red popup that says:

(!) Fetching Failed!

Using the devtools in Chrome, I can see what it's doing I believe is actually directly hitting my GHE instance API but from the web browser? However, it's not my web browser that knows the API Auth Token to use, and so my instance is returning me a 401 unauthorized. I wonder if this needs to be routed through the Backstage proxy in some fashion or another, and the link in this widget to be re-written for that purpose?

Any other suggestions or ideas?

README suggests to implement deprecated composability

Expected Behavior

README reflects the current steps to install the plugin.

Current Behavior

Following the README, implements a deprecated router:

https://github.com/RoadieHQ/backstage-plugin-github-insights#plugin-setup

VS Code showing me it's deprecated:

Possible Solution

Updates to the README.

Steps to Reproduce

1. Step 1
2. Step 2
3. ...

Context

I just took a newly created app and followed the instructions, realizing out of the box the router as defined was marked as @deprecated. So I know the composability work was changed recently, and sounds like this plugin was also, so the README may just need some small tweaks.

Your Environment

• Plugin Version (version of this software e.g. v0.4.3):
• Backstage version (e.g. 0.1.1-alpha23):
• NodeJS Version (e.g. v12):
• Operating System and Version (e.g. Ubuntu 14.04):
• Browser Information (e.g. chrome 85):