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

The problem is not that teams chose the wrong execution platform. The problem is that the product-level quality story is fragmented across several executions.

Use the execution system you already operate

GitHub Actions and Azure DevOps already know 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 or pipeline definitions;
  • the CI/CD provider owns execution, runners, dependencies, and secrets;
  • the TestOps layer owns source configuration, campaign scope, coordination, status, and the returned quality evidence.

QaCockpit Cloud dispatches only discovered and validated provider configurations. It does not send an internal portal_run_id as a workflow input and does not require a special run name. Provider runs are correlated through provider identity and bounded, tenant-scoped execution context.

A campaign is a collection session

The value of a campaign is broader than a button that starts several workflows. A campaign defines the evidence required for a shared regression or release report.

For each required Test Source, the team can start a new Test Execution or use an existing completed execution already recorded in QaCockpit Cloud. This makes the model useful even when some workflows are started on a schedule, manually in CI/CD, or through another delivery process.

The final Campaign Run keeps:

  • the required source slots;
  • whether each slot started a new execution or attached existing evidence;
  • provider and attempt context;
  • collection completeness;
  • test outcomes and missing scope;
  • failure clusters and protected artifacts;
  • a durable report that can be reviewed after the provider run is gone from daily view.

QaCockpit Cloud Campaign Run Report showing result distribution, source-report completeness, complete and partial scope, and the exact outcome of each required Test Source.

The campaign combines several source executions while preserving workflow, result intake, and test outcome as separate signals.

Keep campaign configuration understandable

Most teams do not need an arbitrary workflow graph inside their TestOps product. A clear campaign name, environment, required Test Sources, and a choice to run new executions together or one by one cover many practical regression patterns.

Technical persistence can support stages and execution profiles without forcing those concepts into the primary user experience. The campaign should read like a quality plan, not an internal data model.

Different scopes should usually be different saved campaigns:

  • Project smoke;
  • Partial regression;
  • Full project regression;
  • Release candidate validation.

This makes the intended evidence explicit and reusable.

Safe provider inputs are part of the boundary

A portal should never accept an arbitrary command from a regular user and forward it to a runner. When a provider workflow exposes supported inputs, QaCockpit Cloud discovers that contract and validates required values, defaults, types, and choices before dispatch.

The application sends only allow-listed values. Secrets remain in the provider secret store, and QaCockpit Cloud environment context is not silently mapped onto an unrelated workflow input.

Coordination should make quality easier to understand

The business value of a campaign is not parallel execution. It is a durable, shared answer to questions that otherwise require pipeline archaeology:

  • Did every required source run or provide usable evidence?
  • What was the final test outcome?
  • Which failures need attention?
  • Which results or artifacts are missing?
  • Can a stakeholder understand the conclusion without learning every repository?

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

QaCockpit Cloud Campaign analytics showing reported pass-rate history and the latest comparable-run delta for one saved campaign.

A saved campaign creates a comparable history without changing how the underlying CI/CD workflows execute.

If your release evidence is assembled from several workflows today, request a quality- landscape review and we will map how a campaign could represent it. Teams centered on Azure DevOps can also explore the Azure DevOps edition.