TiDB Cloud UI
dev: [](https://app.netlify.com/sites/dbaas-dev/deploys)
prod: [](https://app.netlify.com/sites/prod-tidbcloud/deploys)
A Dashboard UI for TiDB Cloud. Powered by [Rsbuild](https://rsbuild.dev/) and [TypeScript](https://www.typescriptlang.org/).
To learn React, check out the [React documentation](https://reactjs.org/).
## Getting Started
First, you need to ensure that there is a TiDB Cloud server proxy available to provide API services (which can refer to [dbaas](https://github.com/pingcap/dbaas) README).
Then, clone a copy of this repo:
```sh
git clone https://github.com/tidbcloud/dbaas-ui
```
> Note: you should make sure [Node](https://nodejs.org/en/) is installed.
Check the node version:
```sh
node -v
```
and run:
> Note: you should run `pnpm gen:api` to generate api files before you start development. For more information about `pnpm gen:api`, please refer to the next section [Contributing and Developing](#contributing-and-developing)
```sh
pnpm i && pnpm gen:api && pnpm start
```
> Note: you should install [pnpm](https://pnpm.io/installation) as the package manager.
Your browser will open automatically to show the TiDB Cloud entry page by default.
## E2E tests
Agent-driven E2E tests use the root dependencies and commands. See [the E2E test guide](test/e2e-agent.md) for configuration, CI groups, and resource cleanup.
```sh
pnpm typecheck:e2e-agent
pnpm test:e2e-agent:unit
```
## Connecting to the backend
To connect to the dev auth0 instance, add the file `.env` with the `domain` and `clientId` of the auth0 application and the `serviceUrl` of the DBaaS endpoint(optional):
```sh
REACT_APP_AUTH0_DOMAIN='tidb-dev.us.auth0.com'
REACT_APP_AUTH0_CLIENTID='KiwWajLJ3pto8SsZ7F35NaqNhwnoRh1c'
REACT_APP_SERVICE_URL='your DBaaS server endpoint' // 'https://us-west-2.nightly.shared.aws.tidbcloud.com' (default)
```
You can change the backend that is connected to from the frontend by changing this setting in the console: `localStorage.setItem('dbaasUrl', URL)`
## Contributing & Developing
For better collaboration and review, we have developed a few rules to help us develop better.
For developing UI logic with OpenAPI, you should check whether the `./swagger.json` in this repository is consistent with the file exported from the backend (`{REACT_APP_SERVICE_URL}/openapi-ui/swagger.json?jwt={AUTH_TOKEN}`), and then run the following script to generate the corresponding api files in `src/dbaas/services/`:
```sh
pnpm gen:api
```
### Security
**MAKE SURE you have [git-secrets](https://github.com/awslabs/git-secrets#installing-git-secrets) installed.**
1. Refer to [here](https://github.com/awslabs/git-secrets/blob/master/README.rst#installing-git-secrets) to install git-secrets.
2. You don't have to install the git hooks in this repo since `Husky` takes over everything, it will run `git secrets --scan` in pre-commit hook with `lint-staged`, you can also find this config in `.lintstagedrc.js`.
### TS or JS
Because we chose vscode as the IDE to develop dashboard, we recommend using the [prettier](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) extension to format our code.
### Theme and Styles
We use `@tidbcloud/uikit` as our primary UI library.
### Git-flow
Generally, we use the `master` branch as the production branch (corresponding to deployments of [tidbcloud.com](https://tidbcloud.com) and [staging.tidbcloud.com](https://staging.tidbcloud.com), where the staging environment is used as the test and verification environment before release), and the `dev` branch as the development branch (corresponding to the deployment of [dev.tidbcloud.com](https://dev.tidbcloud.com)).
In periodic iterative development, each new feature development or bug fix needs to checkout a new branch from the `dev` branch to submit commits, and then merge commits into the `dev` branch by a Pull Request (this will trigger the deploy hook of the dev environment in Netlify).
For every release, you need to checkout a new `release` branch to pick relevant commits and create a Pull Request to `master` branch (the deploy hook of the staging environment in Netlify will be triggered after the PR is merged).
After the verification and testing of the staging environment are completed, the administrator needs to manually publish the release to the production environment.
> Note: After each release is launched, please reset the `dev` branch to be consistent with the `master` branch, and **DELETE** the `release` branch and other merged branches in time
If there is an urgent hotfix, you can directly check out a `hotfix` branch from the `master` to fix it.
### Branch Naming
The naming convention of branches is `{prefix}/{description}`
- **feat**: features development such as feat/rbac
- **fix**, **hotfix**: bug fix, such as fix/billing-status, hotfix/typos
- **refine**, **polish**: UI polish or refine of logic implementation, such as polish/table-pagination, refine/api-client
- **chore**, **docs** and other cases, such as chore/readme, docs/overview
- **release-[date]**: release branch such as release-20201125
#### Commit Message
We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) as a unified writing specification for commit messages.
#### PR Writing Specification
- What problem does this PR solve (related issues)?
- What is changed and how does it work?
- Checklist
- Does this PR introduce a UI change? (screen shots）
## Authors
Originally designed by PingCAP TiDB Cloud Team.