chore: add deployment_id to ProjectUpdate proto

[lionello]

Description

• add deployment ID (etag)
• remove unused Event message
• remove unused Publish rpc

Linked Issues

Checklist

• I have performed a self-review of my code
• I have added appropriate tests
• I have updated the Defang CLI docs and/or README to reflect my changes, if necessary

Summary by CodeRabbit

• Removed Features

  • Message publishing endpoints and related client publish/send commands have been removed across the CLI and service surface.

• API Changes

  • Project update payloads now include an Etag (deployment ID) field to improve tracking of deployments.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

The PR removes the Publish RPC and all related plumbing (client interface method, gRPC/Connect client wrapper, and CLI SendMsg) and deletes the PublishRequest and Event protobuf messages. Separately, it adds a new exported field Etag to ProjectUpdate.

Changes

Cohort / File(s)	Summary
Client interface & gRPC client src/pkg/cli/client/client.go, src/pkg/cli/client/grpc.go	Deleted Publish from FabricClient and removed the GrpcClient.Publish method.
CLI message helper src/pkg/cli/sendMsg.go	Removed SendMsg function (validation, UUID generation, dry-run handling, and Publish invocation).
Generated Connect code src/protos/io/defang/v1/defangv1connect/fabric.connect.go	Removed all Publish-related constants, client/handler fields and methods, handler wiring, and routing for the Publish RPC.
Protobuf definitions src/protos/io/defang/v1/fabric.proto	Removed Publish RPC and the PublishRequest and Event messages; added Etag string field to ProjectUpdate.
BYOC clients src/pkg/cli/client/byoc/... (aws/byoc.go, do/byoc.go, gcp/byoc.go)	ProjectUpdate marshaling updated to include the new Etag field; minor protobuf unmarshalling variable-style adjustments.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Add execution_id to ProjectUpdate protobuf to allow cd to record it #1784: Modifies ProjectUpdate protobuf fields (other field additions) — overlaps at the protobuf message level.
• Always use etag for gcp cdCommands, remove useless code #1772: Changes GCP BYOC client handling around etag propagation — related in BYOC client code.
• Fix panic in defang compose config #1901: Alters the FabricClient interface surface — related to client API changes.

Suggested reviewers

• edwardrf
• jordanstephens

Poem

🐰
I thumped my foot and nibbled Publish away,
No more events to send this bright day.
The proto grew an Etag—so tidy and neat,
Clients get slimmer on nimble feet.
Hop, hop, I cheer for the smaller feat. 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title describes adding a deployment_id field to ProjectUpdate proto, which aligns with the main change of adding an etag field to the ProjectUpdate message in the protobuf file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch lio/add-deployment-id-projectupdate

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.5.0)

level=warning msg="[linters_context] running gomodguard failed: unable to read module file go.mod: current working directory must have a go.mod file: if you are not using go modules it is suggested to disable this linter"
level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies"

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

src/protos/io/defang/v1/fabric.proto (2)

632-646: Align deployment_id naming with existing etag fields.

Most messages use etag for the deployment identifier, while ProjectUpdate introduces deployment_id. Consider standardizing the field name for API consistency (e.g., use etag here or rename others before release).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/protos/io/defang/v1/fabric.proto` around lines 632 - 646, ProjectUpdate
defines the deployment identifier as deployment_id which is inconsistent with
the rest of the API that uses etag; change the field name in the ProjectUpdate
message from deployment_id to etag (keep the same field number and type: string
= 13) and update all references/usages and generated code accordingly so
consumers still receive the same wire-format but use the standardized field name
(also search for ProjectUpdate and any serializers/deserializers to rename
usages).

---

238-247: Naming inconsistency: consider using etag consistently across all messages.

Most messages use etag for the deployment identifier (DeployResponse, ServiceInfo, TailRequest, LogEntry, TailResponse, PreviewRequest, PreviewResponse), but ProjectUpdate uses deployment_id at tag 13. Both include comments indicating they refer to the same concept. Standardizing on a single field name would improve API consistency.

All tag numbers are assigned sequentially without reuse or conflicts—no breaking compatibility issues detected.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/protos/io/defang/v1/fabric.proto` around lines 238 - 247, ProjectUpdate
uses the field deployment_id (tag 13) while other messages use etag for the same
deployment identifier; update ProjectUpdate to use the same field name etag
(replacing deployment_id) and preserve tag 13 and its comment, ensuring
consistency with messages like DeployResponse, ServiceInfo, TailRequest,
LogEntry, TailResponse, PreviewRequest, and PreviewResponse; adjust any
generated code/refs that reference ProjectUpdate.deployment_id to
ProjectUpdate.etag to keep the API consistent.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/protos/io/defang/v1/fabric.proto`:
- Around line 632-646: ProjectUpdate defines the deployment identifier as
deployment_id which is inconsistent with the rest of the API that uses etag;
change the field name in the ProjectUpdate message from deployment_id to etag
(keep the same field number and type: string = 13) and update all
references/usages and generated code accordingly so consumers still receive the
same wire-format but use the standardized field name (also search for
ProjectUpdate and any serializers/deserializers to rename usages).
- Around line 238-247: ProjectUpdate uses the field deployment_id (tag 13) while
other messages use etag for the same deployment identifier; update ProjectUpdate
to use the same field name etag (replacing deployment_id) and preserve tag 13
and its comment, ensuring consistency with messages like DeployResponse,
ServiceInfo, TailRequest, LogEntry, TailResponse, PreviewRequest, and
PreviewResponse; adjust any generated code/refs that reference
ProjectUpdate.deployment_id to ProjectUpdate.etag to keep the API consistent.