-
Notifications
You must be signed in to change notification settings - Fork 204
Add InChainDeploymentPlannable RPC #2832
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
Conversation
|
Code coverage for golang is
|
| prevBlock := dc.Blocks[req.Deployment.DeploymentChainBlockIndex-1] | ||
| plannable := true | ||
| for _, node := range prevBlock.Nodes { | ||
| dp, err := a.deploymentStore.GetDeployment(ctx, node.DeploymentRef.DeploymentId) |
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 think we need the deployment status in the chain model for rendering on the web so how about having that status field in the node. Then we can use it directly instead of retrieving from DB like this.
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.
In that case, when piped submits deployment status (planed, running, etc) we also need to update its status in deployment chain model too, that's quite annoying. How do you think about adding just IsCompleted to the deploymentRef in the chain model?
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.
In the second thought, status is required for showing in the UI, so I think I will go with your suggestion 👍
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.
@nghialv Can I add a TODO note here and address it later since that change requires updates in other RPCs unrelated to this PR.
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.
Addressed by e883d32
|
Code coverage for golang is
|
|
Code coverage for golang is
|
|
/lgtm |
Co-authored-by: Naoto Ono <[email protected]>
|
Code coverage for golang is
|
| return nil, status.Error(codes.InvalidArgument, "invalid deployment with chain block index provided") | ||
| } | ||
|
|
||
| prevBlock := dc.Blocks[req.Deployment.DeploymentChainBlockIndex-1] |
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.
Since DeploymentChainBlockIndex is int32 which is signed integer whose range is -2147483648 to 2147483647, this is a bit likely to be panic.
How about making DeploymentChainBlockIndex an unsigned integer, or adding a simple validation?
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.
Nice catch, golang does not support negative indexes for slide, right? In that case, lets me address it in a separated PR since other place that not related to this change need to be updated 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.
Fine to me 👍
pkg/model/deployment.go
Outdated
| } | ||
|
|
||
| // IsCompletedSuccessfullyDeployment checks whether the deployment is successfully addressed. | ||
| func IsCompletedSuccessfullyDeployment(status DeploymentStatus) bool { |
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.
nit: I feel like this is more natural but it's on you
| func IsCompletedSuccessfullyDeployment(status DeploymentStatus) bool { | |
| func IsSuccessfullyCompletedDeployment(status DeploymentStatus) bool { |
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.
okay, lets me adopt your suggestion 🙆
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.
addressed by 640e172
…cd/pipe into add-check-deployment-plannable-rpc
|
The following ISSUES will be created once got merged. If you want me to skip creating the issue, you can use Details1. Consider add deployment status to the deployment ref in the deployment chain modelThis was created by todo plugin since "TODO:" was found in ac17a84 when #2832 was merged. cc: @khanhtc1202. |
|
Code coverage for golang is
|
|
Keep it up! |
|
/approve |
**What this PR does / why we need it**: - Remove unused ChainBlockIndex field from DeploymentChain model's block - Change type of DeploymentChainBlockIndex from `int32` to `uinit32` **Which issue(s) this PR fixes**: As discussed in #2832 (comment) **Does this PR introduce a user-facing change?**: <!-- If no, just write "NONE" in the release-note block below. --> ```release-note NONE ``` This PR was merged by Kapetanios.
**What this PR does / why we need it**: **Which issue(s) this PR fixes**: Follow PR #2832 **Does this PR introduce a user-facing change?**: <!-- If no, just write "NONE" in the release-note block below. --> ```release-note NONE ``` This PR was merged by Kapetanios.
What this PR does / why we need it:
This PR adds an RPC which be used by piped to determine whether to start planning a deployment that is triggered by the DeploymentChain model.
Which issue(s) this PR fixes:
Follow PR #2815
Does this PR introduce a user-facing change?: