New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(page-services): add jobs #392
Conversation
A preview environment was automatically created via Qovery. Another comment will be posted when deployments are terminated |
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 74a3f6d. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this branch ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
Codecov Report
@@ Coverage Diff @@
## staging #392 +/- ##
===========================================
- Coverage 57.83% 53.70% -4.13%
===========================================
Files 24 298 +274
Lines 268 5554 +5286
Branches 92 1179 +1087
===========================================
+ Hits 155 2983 +2828
- Misses 79 2189 +2110
- Partials 34 382 +348
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the DE improvment with the dataDatabase and others trick.
Now in order to make the whole things easier to read and maintain, I'm proposing an light improvement, tell me what you think about it.
@@ -183,9 +198,12 @@ export const fetchApplicationDeployments = createAsyncThunk< | |||
DeploymentHistoryApplication[], | |||
{ applicationId: string; serviceType?: ServiceTypeEnum; silently?: boolean } | |||
>('application/deployments', async (data) => { | |||
console.log(data.serviceType) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yop
@@ -183,9 +198,12 @@ export const fetchApplicationDeployments = createAsyncThunk< | |||
DeploymentHistoryApplication[], | |||
{ applicationId: string; serviceType?: ServiceTypeEnum; silently?: boolean } | |||
>('application/deployments', async (data) => { | |||
console.log(data.serviceType) | |||
let response | |||
if (data.serviceType === ServiceTypeEnum.CONTAINER) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For these 3 conditions can we have an util somewhere that contains these 3 methods:
isContainer()
isJob()
isApplication() ?
Like this it would be factorised somewhere and if one day the condition to detect the type changes, we just have to change it in one place. What do you think?
<Icon name={type === ServiceTypeEnum.DATABASE ? IconEnum.DATABASE : IconEnum.APPLICATION} width="20" /> | ||
<Icon | ||
name={ | ||
type === ServiceTypeEnum.APPLICATION || type === ServiceTypeEnum.CONTAINER |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this multiplication of rather complex tests here and there, I think even more about the util that contains isContainer() isGitApplication() isDatabase() isJob()
It would be much comfortable to read and to maintain no?
@@ -108,25 +116,34 @@ export function TableRowServices(props: TableRowServicesProps) { | |||
<Skeleton className="w-full" show={isLoading} width={160} height={16}> | |||
<div className="w-full flex gap-2 items-center -mt-[1px]"> | |||
{type === ServiceTypeEnum.APPLICATION && ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because with just these conditions we have to make the effort everytime to see if you test if it's an gitapp, a container app, etc... Frontend joining us could be lost quickly and so could we after many months
@@ -45,33 +46,39 @@ export function TableRowServices(props: TableRowServicesProps) { | |||
isLoading, | |||
} = props | |||
|
|||
const dataDatabase = data as DatabaseEntity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this
} from '@qovery/shared/interfaces' | ||
import { ServiceTypeEnum } from '../service-type.enum' | ||
|
||
export const getServiceType = (data: ApplicationEntity | DatabaseEntity) => { | ||
let currentType: ServiceTypeEnum | ||
|
||
const isJob = (data as JobApplicationEntity).max_nb_restart | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so basically this file already exists, I think you could add some utils in this one that are: isDatabase(data) and that basically would check that getServiceType(data) === ServiceType.DATABASE you see?
import { LoadingStatus } from '../types/loading-status.type' | ||
import { ServiceRunningStatus } from './service-running-status.interface' | ||
|
||
export interface JobApplicationEntity extends JobResponse { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not JobEntity ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it's the same pattern with other application
job-application.entity.ts
git-application.entity.ts
container-application.entity.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, others are really applications, a git and a container give an application. For me, a Job is a Job, but anyway, it's not a big problem, it's totally fine like this too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This refactoring is a bless! Thanks Remi, I'm very happy with this PR!
} else { | ||
currentType = ServiceTypeEnum.APPLICATION | ||
} | ||
|
||
return currentType | ||
} | ||
|
||
// Job | ||
export const isJob = (data?: ApplicationEntity | ServiceTypeEnum) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfecto me gusta mucho!!
import { LoadingStatus } from '../types/loading-status.type' | ||
import { ServiceRunningStatus } from './service-running-status.interface' | ||
|
||
export interface JobApplicationEntity extends JobResponse { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, others are really applications, a git and a container give an application. For me, a Job is a Job, but anyway, it's not a big problem, it's totally fine like this too.
🎉 This PR is included in version 1.2.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
What does this PR do?
> Link to the JIRA ticket
PR Checklist
Global
Store
NX
feature
,ui
,data
,utils
Clean Code