-
Notifications
You must be signed in to change notification settings - Fork 903
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
Improve FAH create & delete #6726
Changes from 4 commits
9766d8d
4850bbd
399c31b
341e39a
cb1546f
3f993de
3e0d5d5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -67,7 +67,7 @@ export type BuildOutputOnlyFields = | |
| "error" | ||
| "image" | ||
| "sourceRef" | ||
| "buildLogUri" | ||
| "buildLogsUri" | ||
| "reconciling" | ||
| "uuid" | ||
| "etag" | ||
|
@@ -196,10 +196,20 @@ export interface RolloutPolicy { | |
// end oneof trigger | ||
stages?: RolloutStage[]; | ||
disabled?: boolean; | ||
|
||
// TODO: This will be undefined if disabled is not true, right? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it should be. |
||
disabledTime: string; | ||
} | ||
|
||
export type RolloutPolicyOutputOnlyFields = "disabledtime"; | ||
export type RolloutPolicyOutputOnlyFields = "disabledTime"; | ||
|
||
export type RolloutPolicyInput = Omit<RolloutPolicy, RolloutPolicyOutputOnlyFields | "stages"> & { | ||
stages: Omit<RolloutStage, "startTime" | "endTime">[]; | ||
}; | ||
|
||
export type TrafficInput = Omit<Traffic, TrafficOutputOnlyFields | "rolloutPolicy"> & { | ||
rolloutPolicy: RolloutPolicyInput; | ||
}; | ||
|
||
export type RolloutProgression = | ||
| "PROGRESSION_UNSPECIFIED" | ||
|
@@ -297,8 +307,8 @@ export async function deleteBackend( | |
location: string, | ||
backendId: string, | ||
): Promise<Operation> { | ||
const name = `projects/${projectId}/locations/${location}/backends/${backendId}?force=true`; | ||
const res = await client.delete<Operation>(name); | ||
const name = `projects/${projectId}/locations/${location}/backends/${backendId}`; | ||
const res = await client.delete<Operation>(name, { queryParams: { force: "true" } }); | ||
|
||
return res.body; | ||
} | ||
|
@@ -374,14 +384,21 @@ export async function updateTraffic( | |
projectId: string, | ||
location: string, | ||
backendId: string, | ||
traffic: Omit<Traffic, TrafficOutputOnlyFields | "name">, | ||
traffic: Omit<TrafficInput, "name">, | ||
): Promise<Operation> { | ||
const fieldMasks = proto.fieldMasks(traffic); | ||
// BUG(b/322891558): setting deep fields on rolloutPolicy doesn't work for some | ||
// reason. Create a copy without deep fields to force the updateMask to be | ||
// correct. | ||
const trafficCopy = { ...traffic }; | ||
if ("rolloutPolicy" in traffic) { | ||
trafficCopy.rolloutPolicy = {} as any; | ||
} | ||
const fieldMasks = proto.fieldMasks(trafficCopy); | ||
const queryParams = { | ||
updateMask: fieldMasks.join(","), | ||
}; | ||
const name = `projects/${projectId}/locations/${location}/backends/${backendId}/traffic`; | ||
const res = await client.patch<Omit<Traffic, TrafficOutputOnlyFields>, Operation>( | ||
const res = await client.patch<TrafficInput, Operation>( | ||
name, | ||
{ ...traffic, name }, | ||
{ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,6 +7,7 @@ import * as poller from "../../../operation-poller"; | |
import * as prompt from "../../../prompt"; | ||
import { createBackend, onboardBackend } from "../../../init/features/apphosting/index"; | ||
import { FirebaseError } from "../../../error"; | ||
import * as deploymentTool from "../../../deploymentTool"; | ||
|
||
describe("operationsConverter", () => { | ||
const sandbox: sinon.SinonSandbox = sinon.createSandbox(); | ||
|
@@ -66,10 +67,10 @@ describe("operationsConverter", () => { | |
repository: cloudBuildConnRepo.name, | ||
rootDirectory: "/", | ||
}, | ||
labels: {}, | ||
labels: deploymentTool.labels(), | ||
}; | ||
|
||
it("should createBackend", async () => { | ||
it("should createBackend with rollout policy", async () => { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nothing here tests to make sure the rollout policy was called. Please add the appropriate logic here to test for that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I may need to revert the label. I originally wrote the test to exercise this but realized it was for a smaller utility function and the larger flow is completely untested. I can either:
You make the call and I'll follow. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, yeah, this isn't actually testing |
||
createBackendStub.resolves(op); | ||
pollOperationStub.resolves(completeBackend); | ||
|
||
|
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, this is odd. According to the approved proposal, the backend ID is supposed to be a required parameter, not a flag. That eliminates the need to pick a backend at all.
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.
Irrespective of the proposal, do you like this better? It seemed odd to me that location could be browsed but backend couldn't. If you like this better we can push it through API council. As an EAP API, do you feel like it is OK to release and then get approval, or should I splice this into another CL until after approval?
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 personally don't like it better, because I hate the prompt selector flow in a CLI 🤷♂️ It's not a wrong thing to do, but I'm assuming that there were product discussions that brought us to the API proposal (as that's a requirement at the top of the document) and that the pattern in the proposal was agreed upon by all the relevant stakeholders already. If you'd like to make a change to what was proposed there, starting back in the process, involving the right people, and getting an addendum would be appropriate.
That said, I thought the general pattern was to:
If someone is outside of us-central1, they get to include the
--location
flag.Having this flow also makes it more complex. Sticking with the picker, you have to also consider what happens in non-interactive environment (like a CI system). As written, this would hang, I believe, which may be unexpected (instead of simply failing out).
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'll move the changes into another branch and bring up the idea in the devx room
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.
(If it's chosen that we should keep the existing dialog, I agree that we need to check for nonInteractive)