Regression rarely consists of one workflow. A realistic release check may combine smoke tests, service tests, browser suites, database verification, and a final end-to-end pass. These scopes can live in different repositories and have different owners.

It is tempting to solve coordination by building a new workflow engine. For most teams, that creates more infrastructure than value.

Use the execution system you already operate

GitHub Actions already knows how to check out code, provision dependencies, access repository secrets, select runners, and execute jobs. Recreating those capabilities inside a TestOps portal would add security risk and duplicate a mature platform.

A smaller and clearer responsibility boundary is possible:

  • repositories own test code and workflow definitions;
  • GitHub Actions owns execution;
  • the TestOps layer owns profiles, campaign structure, dispatch, status, and the returned quality evidence.

In this model, a workflow explicitly supports workflow dispatch. QaCockpit starts it with defined inputs and a portal run identifier, then correlates the provider run and uploaded results with the correct execution attempt.

Campaigns need only a few strong concepts

An effective first campaign model does not need arbitrary graphs or a scripting language. Sequential stages and parallel profiles inside a stage cover many regression patterns:

  1. Run a fast smoke stage.
  2. If it succeeds, start browser, API, and database profiles in parallel.
  3. Continue to a final critical-path stage.

Each profile remains reusable outside the campaign. Each dispatch produces an attempt. Policy can decide whether a failed stage stops the campaign or allows later work.

Safe inputs are part of the design

A portal should never accept an arbitrary command from a regular user and forward it to a runner. Instead, administrators define forms that map allowed values to known workflow inputs. Users select an environment, browser, tag, or data set from those constraints.

That keeps execution flexible without turning the product into a remote shell.

Coordination should make CI easier to understand

The value of a campaign is not the dispatch button. It is the durable record around the dispatch: intended scope, stage structure, provider runs, attempts, results, missing evidence, failures, and artifacts.

That is enough structure to operate regression across repositories while leaving the execution platform exactly where it belongs.