roadiehq / roadie-backstage-plugins Goto Github PK

Feature Suggestion
Add a Build Metrics card showing the available pipeline metrics: average build time, reliability, and build frequency.

Possible Implementation
These metrics are already available from the Buildkite GraphQL API, and we've built out a component to show them:

This has been worked on as a contribution by https://github.com/jessebye/backstage-plugin-buildkite-metrics
https://github.com/RoadieHQ/backstage-plugin-buildkite/issues/38

This was reported internally.

We're not 100% sure what caused the failure but @Xantier was able to reproduce the error by placing an empty code block in a Readme and loading it into Backsage.

looks to be coming from MarkdownContent component which is in backstage-core
which uses react-syntax-highlighter package as the code block rendering lib

See the #ops channel for more conversation.

Feature Suggestion

Currently, releases are published to npm: https://www.npmjs.com/package/@roadiehq/backstage-plugin-jira . It would be nice to have them listed at https://github.com/RoadieHQ/backstage-plugin-jira/releases too, with a changelog if possible.

Possible Implementation

Not sure how this is done with GitHub actions.

Context

To view the changes between the releases, and also to use GitHub to notify me of any releases for this repo.

Feature Suggestion
To have a way to exclude bots in the activity stream view of the card.

Possible Implementation
In https://github.com/RoadieHQ/backstage-plugin-jira/blob/main/src/api/index.ts#L179, it's possible to include a username is not criteria, if the configuration has any exclusions.

Or have a filter to exclude certain usernames.

Context
The stream can get bogged down by bots that have a Jira integration. This can clutter up the stream with unwanted activity.

(https://github.com/RoadieHQ/backstage-plugin-jira/issues/108#issue-950736655)

Currently the support box looks like this:

This support box should:

1. Link to the Roadie discord channel so that people can go there to ask questions.
2. Link to the GitHub repo so that people can go there to open issues.
3. Indicate that the plugin was created by Roadie and link to roadie.io so that people can ask us for help.

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins README file and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

Feature Suggestion

Allow actions

Possible Implementation

Maybe add a sync button after the app name?

Context

Is it possible to perform actions to the argocd application (like sync, rollback) on the backstage dashboard, without the need to go to argocd dashboard?

https://github.com/RoadieHQ/backstage-plugin-argo-cd/issues/66

In my organization, we have the GitHub Actions CI/CD Card on the same tab as the ArgoCD History Card.

The GH Actions are ordered in descending order, with newest run on top, while the ArgoCD History is ordered in the opposite direction, with the oldest event on top.

Feature Suggestion

I propose that a new Boolean prop should be added to this component which can choose between ascending and descending order. I also propose that the default be the opposite of what it is now, since it seems a lot more natural that way (to me, at least). I wouldn't think users should have to scroll down to view the latest syncs, which is what they would be most interested in.

Possible Implementation

With the prop, the history can just be mapped in reverse order. I can easily make a MR if this feature is a good idea, seems like a perfect first issue.

Context

Just trying to make things a bit nicer. This plugin is awesome, and is super useful at our org. Would be awesome to help improve it.

Thanks for checking my idea out!

It appears that these plugins won't work with github enterprise instances. If that's not the case can you add docs for how to configure the correct auth? If that is the case, I think that it's worth investing in adding support. I assume many of the users of backstage will be running private github installs and being able to pull insights from it would be very powerful.

Hi,
I installed the plugin (https://roadie.io/backstage/plugins/github-insights) in my backstage but I recive an error:"The github.com/project-slug annotation is missing. You need to add the annotation to your component if you want to enable this tool.”

In my component the annotation is present

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: cdn
  description: CDN
  annotations:
    github.com/project-slug: savez/cdn

How can i solve the problem?

The following ugly error shows up in the browser console when using the jira plugin.

react-dom.development.js:89 Warning: validateDOMNesting(...): <div> cannot appear as a descendant of <p>.
    in div (created by Styled(MuiBox))
    in Styled(MuiBox) (created by BottomLink)
    in p (created by ForwardRef(Typography))
    in ForwardRef(Typography) (created by WithStyles(ForwardRef(Typography)))
    in WithStyles(ForwardRef(Typography)) (created by BottomLink)
    in div (created by Styled(MuiBox))
    in Styled(MuiBox) (created by BottomLink)
    in a (created by Link)
    in Link (created by ForwardRef(Typography))
    in ForwardRef(Typography) (created by WithStyles(ForwardRef(Typography)))
    in WithStyles(ForwardRef(Typography)) (created by ForwardRef(Link))
    in ForwardRef(Link) (created by WithStyles(ForwardRef(Link)))
    in WithStyles(ForwardRef(Link)) (created by ForwardRef)
    in ForwardRef (created by BottomLink)
    in div (created by BottomLink)
    in BottomLink (created by InfoCard)
    in ErrorBoundary2 (created by InfoCard)
    in div (created by ForwardRef(Paper))
    in ForwardRef(Paper) (created by WithStyles(ForwardRef(Paper)))
    in WithStyles(ForwardRef(Paper)) (created by ForwardRef(Card))
    in ForwardRef(Card) (created by WithStyles(ForwardRef(Card)))
    in WithStyles(ForwardRef(Card)) (created by InfoCard)
    in InfoCard (at JiraCard.tsx:105)

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins README file and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

Hi! I'm wondering if it's possible to use Github Apps Auth for fetching github insights and pull requests, as opposed to using the Github OAuth Authentication Provider.

Thanks!

Currently the support box looks like this:

This support box should:

1. Link to the Roadie discord channel so that people can go there to ask questions.
2. Link to the GitHub repo so that people can go there to open issues.
3. Indicate that the plugin was created by Roadie and link to roadie.io so that people can ask us for help.

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins README file and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

lerna publish is not publishing npm packages but bumping version still creates tags which creates inconsistencies and unexpected behaviours.

Problems:

• NPM auth token is not being used by lerna publish
• backstage-cli backend:bundle errors out
• dist folder is created at the root folder instead of inside each plugin folder

Feature Suggestion

We'd like to tie the Jira plugin to a person instead of a project. (i.e., we'd want a card to show information about the current user's interactions with Jira rather than a particular Jira project's) We're trying to use backstage to show an "at a glance" what a user may be interested in, and in our particular ecosystem it's reasonably likely that a human will have multiple Jira projects that they'd be interested in.

Possible Implementation

Unsure, sorry! Have not done the requisite research to be able to offer constructive suggestions yet.

When trying to update plugins in my backstage instance this afternoon, I discovered broken imports after updating this plugin to 1.1.12. 1.1.11 still works properly. According to the NPM package registry, the previous version of the plugin was about 200KB, and the new version is just over 17KB. I think the package for the 1.1.12 version is broken or missing some pieces.

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins README file and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

The @backstage/core-components should be at release ^0.3.1 in the @roadiehq/backstage-plugin-github-pull-requests@^1.0.12" package, but when you pull down that package, that dependency is pinned to 0.2.0 which is causing issues with backstage.

see: https://cdn.jsdelivr.net/npm/@roadiehq/[email protected]/package.json

and my yarn.lock after specifying @roadiehq/backstage-plugin-github-pull-requests@^1.0.12

"@roadiehq/backstage-plugin-github-pull-requests@^1.0.12":
  version "1.0.12"
  resolved "https://registry.yarnpkg.com/@roadiehq/backstage-plugin-github-pull-requests/-/backstage-plugin-github-pull-requests-1.0.12.tgz#96a3afbce27bfdc75d766c800a317baf4588405c"
  integrity sha512-LscobaeWIatTFqQnBqF+xG6fsu0rPrU7z+sOrbjGCuIo2a4sYhdgnbwYqVWTH2LRb6o8G4K24CYFYC1uQkNkCw==
  dependencies:
    "@backstage/catalog-model" "^0.9.0"
    "@backstage/core-app-api" "^0.1.3"
    "@backstage/core-components" "^0.2.0"
    "@backstage/core-plugin-api" "^0.1.3"
    "@backstage/plugin-catalog-react" "^0.4.0"
    "@material-ui/core" "^4.11.0"
    "@material-ui/icons" "^4.9.1"
    "@octokit/rest" "^18.5.3"
    "@octokit/types" "^5.0.1"
    "@types/node-fetch" "^2.5.7"
    history "^5.0.0"
    moment "^2.27.0"
    node-fetch "^2.6.1"
    react "^16.12.0"
    react-dom "^16.12.0"
    react-router "6.0.0-beta.0"
    react-use "^17.2.4"
    ```

The current behaviour of the plugin is to provide a summary of the opened issues filtering by component (jira/component) and project (jira/project-key) as well as displaying the activity stream for the whole project.

Would it be possible to make it so that the "Activity stream" shows only the activity for the issues related to the Component identified by the annotation jira/component rather than displaying the activity for the whole project jira/project-key ?

In my organization, we have the GitHub Actions CI/CD Card on the same tab as the ArgoCD History Card.

The GH Actions are ordered in descending order, with newest run on top, while the ArgoCD History is ordered in the opposite direction, with the oldest event on top.

Feature Suggestion

I propose that a new Boolean prop should be added to this component which can choose between ascending and descending order. I also propose that the default be the opposite of what it is now, since it seems a lot more natural that way (to me, at least). I wouldn't think users should have to scroll down to view the latest syncs, which is what they would be most interested in.

Possible Implementation

With the prop, the history can just be mapped in reverse order. I can easily make a MR if this feature is a good idea, seems like a perfect first issue.

Context

Just trying to make things a bit nicer. This plugin is awesome, and is super useful at our org. Would be awesome to help improve it.

https://github.com/RoadieHQ/backstage-plugin-argo-cd/issues/74

• Delete @backstage/core
• use instead the smaller core dependencies
• update other dependencies
• TBD

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins README file and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

It would be great if we could get a release notes/changelog on what has changed in a new release and if we need to update something in our installation.
Similar to what backstage is doing: https://github.com/backstage/backstage/releases/tag/release-2021-07-08

If you have multiple GitHub integrations setup in app-config.yaml, currently this plugin only uses the first one.

integrations:
github:
- host: github.com
token:
$env: GITHUB_TOKEN
- host: github.domain.com
apiBaseUrl: https://github.domain.com/api/v3
token:
$env: GHE_TOKEN

Feature Suggestion
Add support for multiple GitHub integrations.

Context
We are using Backstage with both public GitHub (github.com) and an enterprise GitHub server.

https://github.com/RoadieHQ/backstage-plugin-github-pull-requests/issues/97

Feature Suggestion

Allow actions

Possible Implementation

Maybe add a sync button after the app name?

Context

Is it possible to perform actions to the argocd application (like sync, rollback) on the backstage dashboard, without the need to go to argocd dashboard?

Feature Suggestion

Add a Build Metrics card showing the available pipeline metrics: average build time, reliability, and build frequency.

Possible Implementation

These metrics are already available from the Buildkite GraphQL API, and we've built out a component to show them:

We would be happy to contribute this to this plugin if you are interested.

Context

We love the Buildkite pipeline overview page that visually shows pertinent metrics like how often builds fail, their average time, etc. And we'd like to see this data represented in Backstage since it's highly valuable to seeing how a service is doing.

We would like to move all the plugins from their single repositories into this monorepo.

We decided to do this to improve testability and development speed. By having the plugins in this repo together with a scaffolded app we can run cypress tests that make sure that updates in dependencies and new features don't break backstage apps for the community.

List of plugins we need to move here:

• github insights
• github pull request
• aws lambda
• jira
• datadog
• argocd
• travis ci
• buildkite
• #168
• security insights

Add the ability to get lambda function information from AWS accounts that are different from where Backstage is running, or where Backstage has been provided AWS credentials.

Support for getting cross-account credentials via an IAM role has been added to backstage-plugin-aws-auth via RoadieHQ/backstage-plugin-aws-auth#41

Possible Implementation

1. Add an additional, optional, field for the lambda annotation aws.com/lambda-role-arn:
2. Support passing the role arn to the getCredentials() operation if it has been specified in the annotation

Context

In my specific implementation, Backstage is running in a particular AWS account, and it's container has a specific instance profile assigned to it. Our lambda functions that I'd like to show within the UI exist in different accounts, and are managed by the separate development teams that manage their microservices. Providing those teams the ability to load function details cross-account is critical to the use of the plugin.

This also acts as a demonstration vehicle for other plugins to adopt the new feature in backstage-plugin-aws-auth.

If you have multiple GitHub integrations setup in app-config.yaml (like shown below), currently this plugin only uses the first one.

integrations:
  github:
    - host: github.com
      token:
        $env: GITHUB_TOKEN
    - host: github.domain.com
      apiBaseUrl: https://github.domain.com/api/v3
      token:
        $env: GHE_TOKEN

Feature Suggestion

Add support for multiple GitHub integrations.

Possible Implementation

I haven't looked at your code yet so I'm not sure.

Context

We are using Backstage with both public GitHub (github.com) and an enterprise GitHub server.

Feature Suggestion

Hi, our Jira instance only allows authentication via Oauth. Is it possible to support using Oauth for this plugin?

Possible Implementation

Context

https://developer.atlassian.com/server/jira/platform/oauth/

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins [README file](https://github.com/RoadieHQ/
  backstage-plugin-firebase-functions/blob/main/README.md) and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

I have an app deployed in three clusters, one of which I just removed. This means the app was properly selected by the selector key, but did not have history attached. The API code errored out because of this.

Expected Behavior
If one of the apps is broken (Status=Unknown), this should not cause the plugin to crash and show nothing. Ideally, it should show the working apps, and then translate the broken app into a user-readable status.

Current Behavior
The API was returning something like this (notice there is no history key).

{
   "metadata":{
      "resourceVersion":...
   },
   "items":[
      ...
      {
         "metadata":{
            ...
         },
         "spec":{
            ...
         },
         "status":{
            "sync":{
               "status":"Unknown",
               ...
            },
            "health":{
               "status":"Healthy"
            },
            "conditions":[
               {
                  "type":"ComparisonError",
                  "message":"rpc error: code = Unknown desc = <cluster>: app path does not exist",
                  "lastTransitionTime":"2021-06-21T21:58:53Z"
               }
            ],
            ...
         }
      }
   ]
}

This IS a valid Argo app, even though it is erroring.

This caused the ArgoCD overview card to display this:
argocd overview
even though there were two working apps.

Here is the error text:

Error occurred while fetching data. Error: remote data validation failed: Expecting Array<{ id: number, revision: string, deployStartedAt: (string | undefined), deployedAt: (string | undefined) }> at items.2.status.history but instead got: undefined; Expecting { finishedAt: string } at items.2.status.operationState but instead got: undefined

Possible Solution
I have not looked at the code, but a try catch around the validation inside this loop could output a simple app error status to be shown to the user.

Steps to Reproduce

1. Create a broken ArgoCD app which is not pointing at a valid GitHub repo path
2. Set up a selector in catalog-info.yaml which selects this broken app
3. Observe that the EntityPage now shows an error instead of the expected app list

Context
It was easy to fix the error by totally deleting the broken app, but this error seems relatively simple to fix and would save future Backstage devs the trouble.

Environment
Node 14, latest version of Backstage (just ran versions:bump this morning).

https://github.com/RoadieHQ/backstage-plugin-argo-cd/issues/77

Feature Suggestion
Support using Oauth for this plugin

Possible Implementation
Context
https://developer.atlassian.com/server/jira/platform/oauth/

https://github.com/RoadieHQ/backstage-plugin-jira/issues/64

Remove Activity Stream completely as there have been some confusions when component name is provided and unfortunately filtering activity stream by component is not supported at the moment(https://support.atlassian.com/confluence-cloud/docs/add-the-activity-stream-gadget/)

https://github.com/RoadieHQ/backstage-plugin-jira/issues/100

Currently, users of our plugins don't really have a way to know when new releases are availalbe.

Can we send an automated discord message to our Discord server when we release a new version? This should work just like the one for Backstage.

Can we send a Tweet from the Roadie Twitter account when we release a new version?

[ch3458]

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins [README file]https://github.com/RoadieHQ/backstage-plugin-jira/blob/main/README.md) and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

We'd like to tie the Jira plugin to a person instead of a project. (i.e., we'd want a card to show information about the current user's interactions with Jira rather than a particular Jira project's) We're trying to use backstage to show an "at a glance" what a user may be interested in, and in our particular ecosystem it's reasonably likely that a human will have multiple Jira projects that they'd be interested in.

https://github.com/RoadieHQ/backstage-plugin-jira/issues/101

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins README file and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

Feature Suggestion

To have a way to exclude bots in the activity stream view of the card.

Possible Implementation

In https://github.com/RoadieHQ/backstage-plugin-jira/blob/main/src/api/index.ts#L179, it's possible to include a username is not criteria, if the configuration has any exclusions.

Or have a filter to exclude certain usernames.

Context

The stream can get bogged down by bots that have a Jira integration. This can clutter up the stream with unwanted activity.

• Update the original plugins README file and explain that the contents have moved
• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Remove all code in the original repository via a PR and leave only the README

• Clone inside backstage-roadie-plugins repository and add to Entity Page
• Write fixtures/mockups for endpoints
• Write tests for the plugin, make sure everything is properly fetched/displayed
• Make sure the Github workflow in this monorepo is publishing the npm package
• Update marketing site instructions
• Update the original plugins README file and explain that the contents have moved
• Remove all code in the original repository via a PR and leave only the README

I have an app deployed in three clusters, one of which I just removed. This means the app was properly selected by the selector key, but did not have history attached. The API code errored out because of this.

Expected Behavior

If one of the apps is broken (Status=Unknown), this should not cause the plugin to crash and show nothing. Ideally, it should show the working apps, and then translate the broken app into a user-readable status.

Current Behavior

The API was returning something like this (notice there is no history key).

{
   "metadata":{
      "resourceVersion":...
   },
   "items":[
      ...
      {
         "metadata":{
            ...
         },
         "spec":{
            ...
         },
         "status":{
            "sync":{
               "status":"Unknown",
               ...
            },
            "health":{
               "status":"Healthy"
            },
            "conditions":[
               {
                  "type":"ComparisonError",
                  "message":"rpc error: code = Unknown desc = <cluster>: app path does not exist",
                  "lastTransitionTime":"2021-06-21T21:58:53Z"
               }
            ],
            ...
         }
      }
   ]
}

This IS a valid Argo app, even though it is erroring.

This caused the ArgoCD overview card to display this:

even though there were two working apps.

Here is the error text:

Error occurred while fetching data. Error: remote data validation failed: Expecting Array<{ id: number, revision: string, deployStartedAt: (string | undefined), deployedAt: (string | undefined) }> at items.2.status.history but instead got: undefined; Expecting { finishedAt: string } at items.2.status.operationState but instead got: undefined

Possible Solution

I have not looked at the code, but a try catch around the validation inside this loop could output a simple app error status to be shown to the user.

Steps to Reproduce

1. Create a broken ArgoCD app which is not pointing at a valid GitHub repo path
2. Set up a selector in catalog-info.yaml which selects this broken app
3. Observe that the EntityPage now shows an error instead of the expected app list

Context

It was easy to fix the error by totally deleting the broken app, but this error seems relatively simple to fix and would save future Backstage devs the trouble.

Your Environment

Node 14, latest version of Backstage (just ran versions:bump this morning).

I've already create a OAuth access token, but seemed not work with plugin.

Could anyone use OAuth as well, but work?