fix(quality-loop): backport GITINTEGRATION actor and mask parent workflow name to release/2-13 - #8160
fix(quality-loop): backport GITINTEGRATION actor and mask parent workflow name to release/2-13#8160buarki wants to merge 3 commits into
Conversation
… flows (#8108) * feat(proto): add GITINTEGRATION actor type for git-provider-triggered flows Adds a new value to the RunningContextType proto enum and to the TestWorkflowRunningContextActorType OpenAPI enum, plus the round-trip mapper cases between them. Downstream consumers (telemetry bucketer, CDEvents mapper) route the new actor into git-integration/event buckets. Kicks off the change needed on the cloud-api side to introduce a provider-agnostic "Git Integration" actor for Quality Loop executions (GitHub today, GitLab and Bitbucket without another proto bump). * fix: allow gitintegration actor in CRD schema and CLI validation * refactor: rename GITINTEGRATION actor to QUALITYLOOP for internal naming * refactor: keep proto RunningContextType_QUALITYLOOP but expose gitintegration to users Proto stays QUALITYLOOP internally per Ole's suggestion. OpenAPI actor type, CRD kubebuilder enum, CLI flag, and telemetry bucket surface as gitintegration so every customer-facing surface (REST API, kubectl testkube, helm charts, generated CRDs) speaks the provider-agnostic name. The mapper cross-translates between the two. * refactor: alias QUALITYLOOP for internal Go references, wire stays gitintegration Adds regen-safe alias files so Go code can reference testkube.QUALITYLOOP_TestWorkflowRunningContextActorType while the underlying wire value stays "gitintegration" for CLI, REST, CRDs, and helm charts. Consumers refactored to use the internal name; customer surfaces unchanged. * chore: fix goimports alignment
…ctor for sticky families (#8119) * feat(controlplaneclient): let chained children inherit the parent's actor for sticky families Today every chained execution is stamped as RunningContextType_EXECUTION, which the server maps to actor.type = testworkflow. That is the right default for regular composites but it does not survive a filter by the Quality Loop actor: the QL parent carries actor.type = gitintegration and the children it schedules end up as testworkflow, so filtering the Executions page by the parent's actor returns an empty list. This introduces a small sticky-actor family: when the parent's actor belongs to it (only QUALITYLOOP for now), the child inherits the parent's actor type instead of falling back to the EXECUTION default. Parent-chain walkers keep working because we extend the QUALITYLOOP mapper branch to populate actor.executionId / actor.executionPath from ParentExecutionIds the same way the EXECUTION branch does. Everything outside the sticky set (user-authored composites, cron/testtrigger/CR-scheduled runs) is byte-identical to today: the default injection path still stamps EXECUTION and the mapper still produces testworkflow. Telemetry buckets, Mixpanel dimensions, and downstream webhooks for non-QL flows are unaffected. * chore: reword sticky-actor comments to reference gitintegration instead of Quality Loop * refactor: move child-context decision onto the actor type via ChildRunningContextType method Reads better at the call site: instead of an external helper that returns (value, ok) and an if-branch to conditionally overwrite the default, the actor type answers directly what its chained children should carry. Injection funnel collapses to: Type: c.opts.ParentActorType.ChildRunningContextType() The default (RunningContextType_EXECUTION, mapped server-side to actor.type = testworkflow / the "Workflow" chip on the Executions page) lives inside the method along with the special cases, so extending it means editing one file next to the type itself. Tests moved from the controlplane client into the same package as the method for the same reason. * chore: drop verbose doc block on ChildRunningContextType * feat(runner): propagate parent RunningContext to child pods via GetExecutionWorkflow The runner builds ExecutionConfig for a scheduled pod from the ExecutionStart proto, which does not carry RunningContext. That leaves cfg.Execution.RunningContext nil in the toolkit; parentActorTypeFromRunningContext returns empty; the sticky family cannot see it's chained under a gitintegration parent and children fall back to actor.type=testworkflow. The runner already makes a follow-up GetExecutionWorkflow call for every ExecutionStart to fetch the enriched workflow. That response is documented as the vehicle for "any additional information that may be related" - the perfect place to attach the parent's actor identity without touching the ExecutionStart proto (which is used by many non-sticky paths). Adds a minimal ExecutionRunningContext projection (actor type + actor name) to GetExecutionWorkflowResponse, populates it server-side from the stored TWE, and reconstructs a TestWorkflowRunningContext on the runner side that parentActorTypeFromRunningContext can read unchanged. When the field is nil (older control planes, non-actor executions), behaviour matches today.
Greptile SummaryThis backport adds the git-integration actor contract and carries that actor through the Control Plane, runner, toolkit, and nested scheduling flow so Quality Loop children display a masked parent name. The source schemas, generated artifacts, standalone implementation, and commercial Control Plane consumer are coordinated, and no blocking defect was identified. Confidence Score: 5/5The PR appears safe to merge, with the Quality Loop actor and child-context propagation implemented consistently across the relevant runtime and protocol boundaries. The parent actor is fetched with the execution, transported through the additive protobuf field, serialized into the toolkit configuration, and converted back into the expected git-integration context for nested schedules. Important Files Changed
Sequence DiagramsequenceDiagram
participant CP as Control Plane
participant Runner
participant Toolkit
participant Scheduler
CP->>Runner: GetExecutionWorkflow(running_context)
Runner->>Toolkit: InternalConfig with parent actor
Toolkit->>Scheduler: Schedule child as QUALITYLOOP
Scheduler->>Scheduler: Rebuild gitintegration actor context
Scheduler-->>CP: Child labeled Git Integration
Reviews (1): Last reviewed commit: "fix(quality-loop): mask parent workflow ..." | Re-trigger Greptile |
What
Cherry-picks 3 commits from
maintorelease/2-13:29ea89d35— feat(proto): add GITINTEGRATION actor type (feat(proto): add GITINTEGRATION actor type for git-provider-triggered flows #8108)df570bb2b— feat(controlplaneclient): sticky-family child actor inheritance (feat(controlplaneclient): let chained children inherit the parent's actor for sticky families #8119)d0ca94397— fix(quality-loop): mask parent workflow name on child running context (fix(quality-loop): mask parent workflow name on child running context #8136)Why
release/2-12diverged before the QL actor type existed, andrelease/2-13was cut before feat(proto): add GITINTEGRATION actor type for git-provider-triggered flows #8108.modify/deleteconflicts, because fix(quality-loop): mask parent workflow name on child running context #8136 touches files introduced by feat(proto): add GITINTEGRATION actor type for git-provider-triggered flows #8108 and feat(controlplaneclient): let chained children inherit the parent's actor for sticky families #8119.Validation
go build ./...passes.go test ./pkg/api/v1/testkube/... ./pkg/controlplaneclient/... -count=1passes.After merge
Cut the next
2.13.xtag and bump the runner pin to it. Child executions will surfaceGit Integrationon the running context name instead of the internal parent workflow name.