|
| 1 | +// Copyright (c) 2025 Uber Technologies, Inc. |
| 2 | +// |
| 3 | +// Licensed under the Apache License, Version 2.0 (the "License"); |
| 4 | +// you may not use this file except in compliance with the License. |
| 5 | +// You may obtain a copy of the License at |
| 6 | +// |
| 7 | +// http://www.apache.org/licenses/LICENSE-2.0 |
| 8 | +// |
| 9 | +// Unless required by applicable law or agreed to in writing, software |
| 10 | +// distributed under the License is distributed on an "AS IS" BASIS, |
| 11 | +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 12 | +// See the License for the specific language governing permissions and |
| 13 | +// limitations under the License. |
| 14 | + |
| 15 | +// Package entity holds Runway's domain entities, including the wire contract for |
| 16 | +// the merge-conflict check queues that Runway owns. The contract crosses a |
| 17 | +// service boundary (SubmitQueue cannot read Runway's storage and vice versa), so |
| 18 | +// these payloads carry the full data needed to perform a merge attempt rather |
| 19 | +// than opaque entity IDs. |
| 20 | +package entity |
| 21 | + |
| 22 | +import ( |
| 23 | + "encoding/json" |
| 24 | + |
| 25 | + "github.com/uber/submitqueue/entity/change" |
| 26 | + "github.com/uber/submitqueue/entity/mergestrategy" |
| 27 | +) |
| 28 | + |
| 29 | +// MergeStep is one step of an ordered merge-conflict check: a single set of |
| 30 | +// change(s) applied with a strategy. Runway applies the steps of a request in |
| 31 | +// order on top of the target branch; the ordering encodes the base-layering |
| 32 | +// (earlier steps are the in-flight base, the last step is the candidate). |
| 33 | +type MergeStep struct { |
| 34 | + // StepID is an opaque, caller-assigned identifier for this step. Runway |
| 35 | + // treats it as an attribution token only — it echoes it back per-step in |
| 36 | + // StepConflict so a multi-step result is attributable — and never interprets |
| 37 | + // its contents. (SubmitQueue happens to use its land-request id here.) |
| 38 | + StepID string `json:"step_id"` |
| 39 | + // Changes are the code change(s) to apply for this step (provider URIs with |
| 40 | + // head commit SHAs; see entity/change.Change). |
| 41 | + Changes []change.Change `json:"changes"` |
| 42 | + // Strategy is how this step's changes are integrated into the target branch. |
| 43 | + Strategy mergestrategy.MergeStrategy `json:"strategy"` |
| 44 | +} |
| 45 | + |
| 46 | +// MergeConflictCheckRequest is the payload SubmitQueue publishes to the |
| 47 | +// TopicKeyMergeConflictCheck queue. The ID is owned by the client (SubmitQueue) |
| 48 | +// so it can record the in-flight check before publishing and correlate the |
| 49 | +// asynchronous result; runway echoes it back unchanged. |
| 50 | +type MergeConflictCheckRequest struct { |
| 51 | + // ID is the client-owned correlation id for this check request (one per |
| 52 | + // request). Runway echoes it back on the result unchanged. |
| 53 | + ID string `json:"id"` |
| 54 | + // QueueName is the SubmitQueue queue the check belongs to. Runway resolves |
| 55 | + // the target branch and provider config per-queue from this name; no target |
| 56 | + // ref is passed. |
| 57 | + QueueName string `json:"queue_name"` |
| 58 | + // Steps is the ordered application sequence: in-flight steps first, the |
| 59 | + // candidate last. A single-element slice expresses "candidate vs target |
| 60 | + // branch". |
| 61 | + Steps []MergeStep `json:"steps"` |
| 62 | +} |
| 63 | + |
| 64 | +// ToBytes serializes the MergeConflictCheckRequest to JSON bytes for the queue payload. |
| 65 | +func (r MergeConflictCheckRequest) ToBytes() ([]byte, error) { |
| 66 | + return json.Marshal(r) |
| 67 | +} |
| 68 | + |
| 69 | +// MergeConflictCheckRequestFromBytes deserializes a MergeConflictCheckRequest from JSON bytes. |
| 70 | +func MergeConflictCheckRequestFromBytes(data []byte) (MergeConflictCheckRequest, error) { |
| 71 | + var req MergeConflictCheckRequest |
| 72 | + err := json.Unmarshal(data, &req) |
| 73 | + return req, err |
| 74 | +} |
| 75 | + |
| 76 | +// StepConflict identifies a single step that failed to apply cleanly during a |
| 77 | +// merge-conflict check, so a multi-step result attributes the conflict. |
| 78 | +type StepConflict struct { |
| 79 | + // StepID echoes the StepID of the step that conflicted (see MergeStep.StepID). |
| 80 | + StepID string `json:"step_id"` |
| 81 | + // Reason is a human-readable explanation of the conflict. |
| 82 | + Reason string `json:"reason"` |
| 83 | +} |
| 84 | + |
| 85 | +// MergeConflictCheckResult is the payload runway publishes to the |
| 86 | +// TopicKeyMergeConflictCheckSignal queue once a check completes. |
| 87 | +type MergeConflictCheckResult struct { |
| 88 | + // ID echoes the client-owned correlation id from the request. |
| 89 | + ID string `json:"id"` |
| 90 | + // Mergeable is true if the whole ordered step sequence applied cleanly. |
| 91 | + Mergeable bool `json:"mergeable"` |
| 92 | + // Reason is a human-readable explanation when Mergeable is false. Empty when mergeable. |
| 93 | + Reason string `json:"reason"` |
| 94 | + // Conflicts optionally attributes the failure to specific steps. May be |
| 95 | + // empty even when Mergeable is false. |
| 96 | + Conflicts []StepConflict `json:"conflicts,omitempty"` |
| 97 | +} |
| 98 | + |
| 99 | +// ToBytes serializes the MergeConflictCheckResult to JSON bytes for the queue payload. |
| 100 | +func (r MergeConflictCheckResult) ToBytes() ([]byte, error) { |
| 101 | + return json.Marshal(r) |
| 102 | +} |
| 103 | + |
| 104 | +// MergeConflictCheckResultFromBytes deserializes a MergeConflictCheckResult from JSON bytes. |
| 105 | +func MergeConflictCheckResultFromBytes(data []byte) (MergeConflictCheckResult, error) { |
| 106 | + var res MergeConflictCheckResult |
| 107 | + err := json.Unmarshal(data, &res) |
| 108 | + return res, err |
| 109 | +} |
0 commit comments