add basic READMEs #14
Conversation
README.md
Outdated
| We believe [Backstage.io](https://backstage.io) can be extended to help developers where they spend the majority of their time: their IDE. This repository contains a collection of plugins that onboard developers faster and reduce context-switching by giving them one-click into reproducible development environments: | ||
|
|
||
| - [backstage-plugin-coder](./plugins/backstage-plugin-coder/README.md): A plugin for integrating Coder workspaces into Backstage. | ||
| - [backstage-plugin-devcontainers](./plugins/backstage-plugin-devcontainers/README.md): A plugin for integrating DevContainers into Backstage (no Coder deployment necessary). |
There was a problem hiding this comment.
will there be a frontend one? right now there is only backstage-plugin-devcontainers-backend
how are READMEs typically handled when there is this "split"?
There was a problem hiding this comment.
Looking at some community examples I think we'll just stick one at plugin root so folks don't have to cobble together information from two different sources (so what you have is fine).
Co-authored-by: Kira Pilot <kira.pilot23@gmail.com>
| mode: 'manual', | ||
| // This parameter is used to filter Coder workspaces | ||
| // by a repo URL parameter. | ||
| repoUrlParamKeys: ['custom_repo', 'repo_url'], |
There was a problem hiding this comment.
Think it might be help to make it more clear that this is specifically for specifying multiple parameters for the repo URL, if a company somehow has multiple teams using different key names
There's a section in the API Reference that mentions the general order of operations that the logic uses to process these parameter names. Might be worth linking to it once the API docs are good to go
There was a problem hiding this comment.
I'm not sure how a single template would be supported, but multiple parameters for repo, unless I'm missing something. I think we leave it in the API reference for now.
| ```ts | ||
| // MyCustomComponent.tsx | ||
| import { useOpenInCoderLink } from '@internal/plugin-coder'; | ||
| 1. Add the `WorkspacesList` card to the entity page in your app: |
There was a problem hiding this comment.
| 1. Add the `WorkspacesList` card to the entity page in your app: | |
| 1. Add the `CoderWorkspacesCard` card to the entity page in your app: |
Do you also think that it's worth shouting out that the individual pieces will be available as imports, too, for people who want more customization options, or can that stay more of a footnote in the API docs?
There was a problem hiding this comment.
Yeah, that would be excellent. Will we have an example of that in the API docs? Left a comment for now.
| // TODO. I believe Michael said this is possible today? | ||
| // This can be a very basic component that requires auth | ||
| // and lists all templates in a basic unstyled list | ||
| // with a refresh button |
There was a problem hiding this comment.
Yeah, this depends on your definition of "possible today".
With the current proxy settings, it is possible to hit any arbitrary endpoint, though there's zero type-safety/type-hints or good ergonomics around it. There's also not a great way to bring the Coder session token from the other UI components into any arbitrary fetch call
Again, though, these changes are perfectly doable in time for launch – they're just not ready quite yet
There was a problem hiding this comment.
Gotcha. Commented out fo rnow
|
|
||
| More ideas welcome! | ||
| - [ ] Add support for only rendering component if `catalog-info.yaml` indicates the item is compatible with Coder |
There was a problem hiding this comment.
I don't think this would be too hard – my gut feeling is that we would basically export a custom hook (something like useCoderCatalogInfo) that exposes a property saying whether the current entity has a YAML config in the current file
I think that'll be the best option for giving devs the most control, since there's so much freedom as far as where the component can be placed, and blindly hiding an element could cause layout jank in our user's webpages. Though on top of this, we could also add a property to the component that says whether to render at all
|
@bpmct, Asher brought up some great points in another ticket:
|
Extracted to #18 |
This is intended to be a starting point, and I am happy to pair and/or take this to completion.
What this is missing:
I believe we already have this content, so it should be somewhat trivial to add/reference. If I am wrong, let me know and perhaps we can adjust to remove this.