|
1 | | -This project was bootstrapped with [Create React App](https://github.com/facebook/create-react-app). |
| 1 | +# Devtron Dashboard |
2 | 2 |
|
3 | | -## Available Scripts |
| 3 | +<p align="start"> |
| 4 | +<a href="https://github.com/devtron-labs/devtron/releases"><img src="https://img.shields.io/github/v/release/devtron-labs/devtron"></a> |
| 5 | +<a href="https://discord.gg/jsRG5qx2gp"><img src="https://img.shields.io/discord/687207715902193673?logo=discord&label=Discord&color=5865F2&logoColor=white" alt="Join Discord"></a> |
| 6 | +<a href="./LICENSE"><img src="https://img.shields.io/badge/License-Apache%202.0-blue.svg" alt="License"></a> |
| 7 | +<img src="https://img.shields.io/github/contributors/devtron-labs/dashboard" alt="contributors"> |
| 8 | +<img src="https://img.shields.io/github/commit-activity/m/devtron-labs/devtron" alt="Commit Activity"> |
| 9 | +</p> |
4 | 10 |
|
5 | | -In the project directory, you can run: |
| 11 | +[](https://github.com/devtron-labs/dashboard/actions/workflows/ci.yml) |
6 | 12 |
|
7 | | -### `yarn start` |
| 13 | +This is the client side web app for [devtron](https://github.com/devtron-labs/devtron). |
| 14 | +This web app is written in [React](https://react.dev/) frontend-library. Uses a typescript + vite for setup. |
8 | 15 |
|
9 | | -Runs the app in the development mode.<br> |
10 | | -Open [http://localhost:3000](http://localhost:3000) to view it in the browser. |
| 16 | +## Local Development |
11 | 17 |
|
12 | | -The page will reload if you make edits.<br> |
13 | | -You will also see any lint errors in the console. |
| 18 | +This project uses `yarn` as package manager. By default the backend is pointed to [https://preview.devtron.ai](https://preview.devtron.ai). To change it, update the `TARGET_URL` in `./vite.config.mts` to your devtron instance url. |
14 | 19 |
|
15 | | -### `yarn test` |
| 20 | +- To install all dependencies and initialize the project just run the command: |
16 | 21 |
|
17 | | -Launches the test runner in the interactive watch mode.<br> |
18 | | -See the section about [running tests](https://facebook.github.io/create-react-app/docs/running-tests) for more information. |
19 | | - |
20 | | -### `yarn run build` |
21 | | - |
22 | | -Builds the app for production to the `build` folder.<br> |
23 | | -It correctly bundles React in production mode and optimizes the build for the best performance. |
24 | | - |
25 | | -The build is minified and the filenames include the hashes.<br> |
26 | | -Your app is ready to be deployed! |
27 | | - |
28 | | -See the section about [deployment](https://facebook.github.io/create-react-app/docs/deployment) for more information. |
29 | | - |
30 | | -### `yarn run eject` |
31 | | - |
32 | | -**Note: this is a one-way operation. Once you `eject`, you can’t go back!** |
33 | | - |
34 | | -If you aren’t satisfied with the build tool and configuration choices, you can `eject` at any time. This command will remove the single build dependency from your project. |
35 | | - |
36 | | -Instead, it will copy all the configuration files and the transitive dependencies (Webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except `eject` will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own. |
37 | | - |
38 | | -You don’t have to ever use `eject`. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it. |
39 | | - |
40 | | -### `commit process` |
41 | | - |
42 | | -- Now before commiting lint will run and check for errors. |
43 | | -- It will not allow to commit if there are lint errors. |
44 | | -- To fix them run `yarn lint-fix` (check package.json). It is not capable of fixing everything so some fixes has to be done manually. |
45 | | - |
46 | | -### Do's |
47 | | - |
48 | | -- Try to make only one state per page rest every thing shall be pure. |
49 | | -- A method should do one and only one thing. |
50 | | -- Do function and variable namings so good you don't need comments. |
51 | | -- While making smaller Components make them reusable. |
52 | | -- Do most of the heavy lifting tasks inside smaller components not in the state component. |
53 | | -- Do all the parsing and error handling on service state component should not get anything more than (success and data) or (error and data). |
54 | | -- Use BEM to name CSS classes and structure it. |
55 | | - |
56 | | -### Don'ts |
57 | | - |
58 | | -- Don't add if else on render add functions which render checks on smaller functions. |
59 | | -- Don't add IDs for CSS if done correctly you never need ids. |
60 | | -- Don't add unnecessary Indentations it doesn't improve readability. |
61 | | -- Never add checks on the basis of text. |
62 | | -- Don't use float use display instead, use display flex-box, inline, inline-block. |
63 | | -- Don't use mix type methods in a class |
64 | | - |
65 | | -### Sentry Config |
66 | | - |
67 | | -- SENTRY_AUTH_TOKEN="" |
68 | | -- SENTRY_ORG="devtron-labs" |
69 | | -- SENTRY_PROJECT="dashboard" |
70 | | -- DSN="" |
71 | | -- SENTRY_TRACES_SAMPLE_RATE="0.2" |
72 | | - |
73 | | -### Sentry sourcemap upload |
74 | | - |
75 | | -```console |
76 | | -foo@bar:~$ sh sentry.sh |
| 22 | +```bash |
| 23 | +yarn install |
77 | 24 | ``` |
78 | 25 |
|
79 | | -### Set custom sentry environment during production deployment, default is staging |
| 26 | +- To start a dev server at [http://localhost:3000](http://localhost:3000), execute: |
80 | 27 |
|
81 | | -```console |
82 | | -foo@bar~$ docker run -p 3000:80 -e SENTRY_ENV=my-custom-env -t artifact/tag |
| 28 | +```bash |
| 29 | +yarn start |
83 | 30 | ``` |
84 | 31 |
|
85 | | -### Disable sentry error logging during production deployment, default enabled |
| 32 | +Check out `package.json` for more scripts. |
86 | 33 |
|
87 | | -```console |
88 | | -foo@bar~$ docker run -p 3000:80 -e ENTRY_ERROR_ENABLED=false -t artifact/tag |
89 | | -``` |
| 34 | +### Commit Process |
90 | 35 |
|
91 | | -### Disable sentry performance monitoring during production deployment, default enabled |
| 36 | +- We use husky to run compile and lint-staged before commit staged changes |
| 37 | +- If husky finds any errors during either the compilation stage or linting stage, the attempt to commit will fail |
| 38 | +- To fix auto-fixable issues, execute: |
92 | 39 |
|
93 | | -```console |
94 | | -foo@bar~$ docker run -p 3000:80 -e SENTRY_PERFORMANCE_ENABLED=false -t artifact/tag |
| 40 | +```bash |
| 41 | +yarn lint-fix |
95 | 42 | ``` |
96 | 43 |
|
97 | | -### Enable Hotjar during production deployment, default disabled |
98 | | - |
99 | | -```console |
100 | | -foo@bar~$ docker run -p 3000:80 -e HOTJAR_ENABLED=false -t artifact/tag |
101 | | -``` |
102 | | - |
103 | | -### Enable google analytics during production deployment, default disabled |
104 | | - |
105 | | -```console |
106 | | -foo@bar~$ docker run -p 3000:80 -e GA_ENABLED=true -t artifact/tag |
107 | | -``` |
108 | | - |
109 | | -### Create test coverage report and save summary in report.txt |
110 | | - |
111 | | -```console |
112 | | -foo@bar~$ npm run test -- --coverage --watchAll=false > report.txt |
113 | | -``` |
114 | | - |
115 | | -### Upload Summary on slack |
116 | | - |
117 | | -```console |
118 | | -foo@bar~$ python uploadTestReport.py |
119 | | -``` |
120 | | - |
121 | | -### Run Following Scripts after release |
| 44 | +### Do's |
122 | 45 |
|
123 | | -```console |
124 | | -foo@bar~$ sh sentry.sh |
125 | | -foo@bar~$ npm run test -- --coverage --watchAll=false > report.txt |
126 | | -foo@bar~$ python uploadTestReport.py |
127 | | -``` |
| 46 | +- Try to make only one state per page rest every thing shall be pure. |
| 47 | +- A method should do one and only one thing. |
| 48 | +- Do function and variable namings so good you don't need comments. |
| 49 | +- While making smaller Components make them reusable. |
| 50 | +- Do most of the heavy lifting tasks inside smaller components not in the state component. |
| 51 | +- Do all the parsing and error handling on service state component should not get anything more than (success and data) or (error and data). |
| 52 | +- Use BEM to name CSS classes and structure it. |
128 | 53 |
|
129 | | -### Development setup with proxy. |
130 | | - |
131 | | -#### **`vite.config.ts`** |
132 | | -Update the `vite.config.ts` file to include the proxy configuration. |
133 | | -In proxy object, add the target URL of the orchestrator and grafana. |
134 | | - |
135 | | -```js |
136 | | -server: { |
137 | | - port: 3000, |
138 | | - proxy: { |
139 | | - '/orchestrator': { |
140 | | - target: 'https://preview.devtron.ai/', |
141 | | - changeOrigin: true, |
142 | | - }, |
143 | | - '/grafana': 'https://preview.devtron.ai/', |
144 | | - }, |
145 | | - } |
146 | | -``` |
| 54 | +### Don'ts |
147 | 55 |
|
148 | | -#### **`.env.development`** |
| 56 | +- Don't add if else on render add functions which render checks on smaller functions. |
| 57 | +- Don't add IDs for CSS if done correctly you never need ids. |
| 58 | +- Don't add unnecessary Indentations it doesn't improve readability. |
| 59 | +- Never add checks on the basis of text. |
| 60 | +- Don't use float use display instead, use display flex-box, inline, inline-block. |
| 61 | +- Don't use mix type methods in a class |
149 | 62 |
|
150 | | -```console |
151 | | -VITE_GRAFANA_ORG_ID=2 |
152 | | -REACT_APP_EDITOR=code |
153 | | -VITE_ORCHESTRATOR_ROOT=/orchestrator |
154 | | -REACT_APP_PASSWORD=argocd-server-74b7b94945-nxxnh |
155 | | -``` |
| 63 | +## How do I make a contribution? |
156 | 64 |
|
157 | | -### Development setup without proxy. |
| 65 | +Never made an open source contribution before? Wondering how contributions work in our project? Here's a quick rundown! |
158 | 66 |
|
159 | | -#### **`.env.development`** |
| 67 | +- Find an issue that you are interested in addressing or a feature that you would like to add. |
| 68 | +- Fork this repository to your local GitHub organization. This means that you will have a copy of the repository under your-GitHub-username/repository-name. |
| 69 | +- Clone the repository to your local machine using: |
160 | 70 |
|
161 | | -```console |
162 | | -VITE_GRAFANA_ORG_ID=2 |
163 | | -REACT_APP_EDITOR=code |
164 | | -VITE_ORCHESTRATOR_ROOT=http://demo.devtron.info:32080/orchestrator |
165 | | -REACT_APP_PASSWORD=argocd-server-74b7b94945-nxxnh |
| 71 | +```bash |
| 72 | +git clone https://github.com/github-username/dashboard.git |
166 | 73 | ``` |
167 | 74 |
|
168 | | -## How do I make a contribution? |
169 | | - |
170 | | -Never made an open source contribution before? Wondering how contributions work in our project? Here's a quick rundown! |
171 | | - |
172 | | -- Find an issue that you are interested in addressing or a feature that you would like to add. |
173 | | -- Fork the repository https://github.com/devtron-labs/dashboard.git to your local GitHub organization. This means that you will have a copy of the repository under your-GitHub-username/repository-name. |
174 | | -- Clone the repository to your local machine using |
175 | | - `git clone https://github.com/github-username/dashboard.git.` |
176 | | -- Create a new branch for your fix using `git checkout -b branch-name-here`. |
177 | | -- Make the appropriate changes for the issue you are trying to address or the feature that you want to add. |
178 | | -- Use `git add insert-paths-of-changed-files-here` to add the file contents of the changed files to the "snapshot" git uses to manage the state of the project, also known as the index. |
179 | | -- Use `git commit -m ‘Insert a short message of the changes made here’` to store the contents of the index with a descriptive message. |
180 | | -- Push the changes to the remote repository using `git push origin branch-name-here`. |
181 | | -- Submit a pull request to the upstream repository. |
182 | | -- Title the pull request with a short description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so "Added failsafe check to resolve #1423". |
183 | | -- In the description of the pull request, explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It's OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it! |
184 | | -- Wait for the pull request to be reviewed by a maintainer. |
185 | | -- Make changes to the pull request if the reviewing maintainer recommends them. |
186 | | -- Celebrate your success after your pull request is merged! |
187 | | - |
188 | | -## How do I run it locally? |
189 | | - |
190 | | -First you need to have the backend project up and running and the dashboard repo cloned on your machine after that follow the below process: |
191 | | - |
192 | | -- Run yarn in the dashboard repo root |
193 | | -- Open the project in your preferred IDE |
194 | | -- Open the `vite.config.ts` file |
195 | | -- Change the target URL of the orchestrator. Replace it with the URL of your orchestrator |
196 | | -- Save the file |
197 | | -- Run `yarn start` |
198 | | -- Go to `localhost:3000` |
199 | | -- Click Login as administrator |
200 | | -- Provide Admin as username and password from Devtron BE |
201 | | -- After login, you will be able to see the dashboard running on your local machine |
202 | | - |
203 | | -## Code walkthrough/Project structure |
204 | | - |
205 | | -We have a `src` folder at the root level which holds everything related to the dashboard |
206 | | - |
207 | | -- `src/assets` have all the image folders like logo, icons, gif etc. These folders have, the related files |
208 | | -- `src/components` have all the components used in the project further divided into folder component specific folders. Specific component folders hold their local CSS file specific to that component, service file specific to that component, and some required child component.tsx as well |
209 | | -- `src/config` has config files like constants, route, etc which holds all the constants, route path constants respectively |
210 | | -- `src/css has` the common CSS files |
211 | | -- `src/services` have the common services used across projects |
| 75 | +- Create a new branch for your fix using `git checkout -b branch-name-here`. |
| 76 | +- Make the appropriate changes for the issue you are trying to address or the feature that you want to add. |
| 77 | +- Use `git add insert-paths-of-changed-files-here` to add the file contents of the changed files to the "snapshot" git uses to manage the state of the project, also known as the index. |
| 78 | +- Use `git commit -m ‘Insert a short message of the changes made here’` to store the contents of the index with a descriptive message. |
| 79 | +- Push the changes to the remote repository using `git push origin branch-name-here`. |
| 80 | +- Submit a pull request to the upstream repository. |
| 81 | +- Title the pull request with a short description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so `fix: Added failsafe check to resolve #1423`. |
| 82 | +- In the description of the pull request, explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It's OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it! |
| 83 | +- Wait for the pull request to be reviewed by a maintainer. |
| 84 | +- Make changes to the pull request if the reviewing maintainer recommends them. |
| 85 | +- Celebrate your success after your pull request is merged! |
0 commit comments