Set up CI for plugins #10
Conversation
code-asher
force-pushed
the
asher/ci
branch
23 times, most recently
from
b373929
to
7954baf
Compare
This will lint, test, and publish individual plugins.
|
One thing missing from this that I think is important is the changelog. But I think we can tackle that in another PR. I think we can use the "generate release notes" button and clean it up when publishing a release for now, but it would be nice to copy that automatically into a |
| on: | ||
| push: | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
I think that main branch is locked down, but this is probably good to have in here anyway.
There was a problem hiding this comment.
This will trigger after merging PRs to main as well! I am not sure we really need to run tests then but I figured it would be safest just in case it ran in the PR without syncing up with main first.
.github/workflows/release.yaml
Outdated
| name: Release | ||
|
|
||
| # This workflow will draft a release for a plugin when tagged. | ||
| # The tag format is <name>/v<version> without the backstage-plugin- prefix. |
There was a problem hiding this comment.
| # The tag format is <name>/v<version> without the backstage-plugin- prefix. | |
| # The tag format is <name>/v<version> without the backstage-plugin- prefix, e.g. coder/v0.0.0 |
| @@ -39,7 +38,7 @@ class ErrorBoundaryCore extends Component< | |||
| } | |||
|
|
|||
| componentDidCatch(error: Error, errorInfo: ErrorInfo): void { | |||
| this.props.onError(error, errorInfo.componentStack); | |||
| this.props.onError(error, errorInfo.componentStack || "no details"); | |||
There was a problem hiding this comment.
Good call with the change. I'm not sure if there are any situations where a component won't naturally have some sort of stack, but always good to have a fallback
There was a problem hiding this comment.
Yeah it seems like one of those things that is never going to happen but the types yell at you anyway. 😆
|
I'm not experienced enough in CI to give much valuable feedback, but this all seems to make sense. Also appreciate you cleaning up some of the TypeScript, too! |
| ```sh | ||
| cd plugins/backstage-plugin-$name | ||
| yarn install | ||
| yarn start |
There was a problem hiding this comment.
Oh is this working now? I thought we were having difficulty running the plugins in isolation for some reason
There was a problem hiding this comment.
Oh yeah it starts but it cannot connect to the backend. If we switch to that API factory stuff then I think it should start working, but for now I should put a note that this does not work for the Coder plugin. Or we could delete it, but I wanted to leave it in as a reminder that we should support this flow.
There was a problem hiding this comment.
Here is what I added:
Note that the Coder plugin does not support running like this as it currently
uses a backend proxy that is not available when running independently of the
Backstage app.
| # because the action fetches changed files through the API. | ||
| - uses: actions/checkout@v4 | ||
| if: github.event_name != 'pull_request' | ||
| - uses: dorny/paths-filter@v3 |
There was a problem hiding this comment.
I did see we were getting rate-limited on Saturday and I don't know how it could possibly pertain to this PR but just mentioning it because I recognized the action name.
There was a problem hiding this comment.
Oh yeah I saw that too. This action uses the API to figure out the changed files so if we hit the limit this action will fail.
I am not sure if the limit is per-repo or per-org, if the former then we probably have nothing to worry about (I imagine this will have fewer commits than coder/coder) but if the latter then it could be a problem.
It might be worth trying a different action tj-actions/changed-files that can detect changes using only the cloned repository, avoiding the API, if we hit limits here as well.
Good idea! Added a nice-to-have ticket. |
There was a problem hiding this comment.
Great work! I learned a lot from reviewing this.
Regarding the tsc change - not sure either. Let's roll with what you've got and see what happens 🤷♀️
I made you a repo admin so you'll be able to add the token when the time comes. Kyle is poking into the coderhq account - stay tuned!
This will lint, test, build, and publish individual plugins. Workflow details are in the readme; let me know if it seems confusing or if the flow can be improved! At the moment it is basically 1) push a tag 2) publish the release on GitHub (after making sure it looks good).
I had to make some changes to get
tscworking (which in turn was required becausebuildtold me to runtscfirst). See the second commit. I am not too sure about the docs addon change in particular.Someone with permissions will need to set
NPM_TOKENin the secrets for this repository for publishing to actually work. But I am not sure which token to use. We probably want some bot account. I see we have acoderhqaccount, maybe we can use that? Need to find out who has access to it, or we can create a new account.Also, the plugin is marked private so we will have to flip that or yarn will refuse to publish.
Closes https://github.com/coder/backstage.cdr.dev/issues/53
Closes #6