Skip to content

fix(quality-loop): backport GITINTEGRATION actor and mask parent workflow name to release/2-13 - #8160

Open
buarki wants to merge 3 commits into
release/2-13from
backport-ql-actor-into-2-13
Open

fix(quality-loop): backport GITINTEGRATION actor and mask parent workflow name to release/2-13#8160
buarki wants to merge 3 commits into
release/2-13from
backport-ql-actor-into-2-13

Conversation

@buarki

@buarki buarki commented Aug 21, 2026

Copy link
Copy Markdown
Collaborator

What

Cherry-picks 3 commits from main to release/2-13:

Why

Validation

  • go build ./... passes.
  • go test ./pkg/api/v1/testkube/... ./pkg/controlplaneclient/... -count=1 passes.

After merge

Cut the next 2.13.x tag and bump the runner pin to it. Child executions will surface Git Integration on the running context name instead of the internal parent workflow name.

buarki added 3 commits August 21, 2026 14:13
… 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.
@buarki
buarki requested a review from a team as a code owner August 21, 2026 17:15
@buarki
buarki requested review from devcatalin and removed request for a team August 21, 2026 17:15
@greptile-apps

greptile-apps Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This 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/5

The 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

Filename Overview
proto/testkube/testworkflow/execution/v1/get_execution_workflow_response.proto Adds a backward-compatible response field carrying the parent actor type and name.
pkg/runner/grpc/client.go Reconstructs the parent running context and includes it in the execution configuration passed to the runtime.
pkg/controlplaneclient/execution_self.go Uses sticky actor rules to classify nested Quality Loop executions and replace the internal parent workflow name.
pkg/testworkflows/testworkflowexecutor/utils.go Adds consistent forward and reverse mappings between gitintegration actors and the QUALITYLOOP protocol type.
pkg/controlplane/agent_grpc_runner.go Projects the standalone parent execution’s actor context into the workflow response.

Sequence Diagram

sequenceDiagram
    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
Loading

Reviews (1): Last reviewed commit: "fix(quality-loop): mask parent workflow ..." | Re-trigger Greptile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant