automationembeddedGitOps

Bringing Timing Analysis into GitOps: Automating RocqStat Runs on Pull Requests

UUnknown

2026-02-12

10 min read

Automate RocqStat in GitOps: run timing analysis on PRs and block merges that violate timing budgets—policy-driven, auditable, and CI-friendly.

Hook: Stop timing regressions from slipping into production — block PRs that violate timing budgets

Too many teams only discover timing regressions after deployment. A change that looks safe in unit tests can push a task over its worst-case execution time (WCET) and trigger system faults in safety-critical or latency-sensitive applications. In 2026 the industry is converging: timing-analysis tools are being treated as first-class verification, and you can — and should — run timing analysis like RocqStat as part of your GitOps premerge checks so pull requests are automatically blocked when they violate timing budgets.

Why bringing timing analysis into GitOps matters in 2026

Two recent trends accelerated this shift. First, timing-analysis tools are being integrated into mainstream test toolchains — for example, Vector's January 2026 acquisition of StatInf's RocqStat highlights how vendors are unifying timing analysis and verification into developer workflows. Second, organizations are adopting stronger policy-as-code and premerge verification practices to meet regulatory and reliability requirements for real-time systems.

Result: Timing analysis is no longer an offline engineering activity. It must be an automated gate in GitOps: code that fails timing budgets should not be merged into the canonical repository that drives production deployments.

High-level architecture: how a timing-analysis gate fits a GitOps workflow

At a glance, the pattern is simple:

Developer opens a pull request (PR) with code changes.
CI is triggered automatically (GitHub Actions, GitLab CI, or an embedded CI) and runs a timing analysis job that executes RocqStat on the changed units/artifacts.
RocqStat produces a machine-readable report (JSON, XML) with WCETs and timing statistics.
A policy engine (simple script, OPA, or a CI step) compares results to the project's timing budget and policy (blocklist/allowlist, critical regions, percentiles).
If any budget is violated, the CI job fails, the PR status is set to failing and branch protection blocks merging. Otherwise, the PR is green and merge is allowed.

Why pre-merge (not just post-merge)?

GitOps principle: the Git repo is the source of truth; only validated artifacts should be merged.
Faster feedback: Developers get immediate guidance in the PR, so fixes are cheaper.
Compliance & traceability: A premerge gate produces artifacts and provenance tied to the PR.

Integration points — where to run timing analysis inside GitOps

CI / premerge checks: Run RocqStat in a CI job triggered by PRs (recommended primary gate).
Embedded CI on feature branch: Lightweight checks that run locally or on ephemeral runners to shorten feedback time.
Pre-sync hooks in GitOps controllers: For teams that prefer a second guard, add pre-sync checks in ArgoCD or Flux to prevent syncs when timing attestations are invalid. See guidance on resilient cloud-native architectures for patterns that include controller-level checks.
Policy engine: OPA / Rego or a custom script enforces budgets and blocklists after the timing job completes.

Practical implementation — a GitHub Actions example (step-by-step)

Below is a compact, realistic workflow that runs RocqStat in a container, extracts the reported WCET for changed functions, compares each to a timing budget stored in the repo, and fails the job if any budget is exceeded. The pattern is portable to GitLab CI or other CI systems.

<!-- .github/workflows/rocqstat-pr.yml -->
name: RocqStat PR Timing Check

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  timing-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Set up Docker image for RocqStat
        run: |
          # Use an image that contains RocqStat and necessary toolchain
          # Replace with your organization's RocqStat container
          echo "ROCQ_IMAGE=myorg/rocqstat:latest" >> $GITHUB_ENV

      - name: Build/prepare binaries (if needed)
        run: |
          # Build your firmware/module or download artifact referenced by PR
          # Example: make build TARGET=unit
          make -C ./src build || true

      - name: Run RocqStat
        run: |
          docker run --rm -v $PWD:/workspace -w /workspace $ROCQ_IMAGE \
            /bin/bash -c "rocqstat analyze --input build/output.elf --format json --output rocqreport.json"

      - name: Show report
        run: cat rocqreport.json

      - name: Compare to timing budgets
        run: |
          # Assumes budgets.json is committed in repo with format {"fnA": 120, "fnB": 50}
          python3 - <<'PY'
import json, sys
with open('rocqreport.json') as f: report = json.load(f)
with open('budgets.json') as f: budgets = json.load(f)
violations = []
# assume report['wcet'] = { 'fnA': 130, 'fnB': 45 }
for name, wcet in report.get('wcet', {}).items():
    budget = budgets.get(name)
    if budget is None: continue
    if wcet > budget:
        violations.append((name, wcet, budget))
if violations:
    print('Timing budget violations detected:')
    for v in violations:
        print(f'{v[0]}: wcet={v[1]} > budget={v[2]}')
    sys.exit(2)
print('All timing budgets OK')
PY

      - name: Upload report artifact
        uses: actions/upload-artifact@v4
        with:
          name: rocq_report
          path: rocqreport.json

Key points:

Use a container image with RocqStat and the toolchain, so CI runners stay lightweight.
Store timing budgets in a versioned file (budgets.json) in the repo to track budget changes together with code changes.
Fail the job explicitly when budgets are exceeded so branch protection can block merges.

Sample RocqStat JSON output (assumed)

{
  "wcet": {
    "task_init": 120.5,
    "process_frame": 23.1,
    "sensor_read": 8.7
  },
  "meta": {
    "analysis_id": "abc123",
    "version": "rocqstat-2026.1"
  }
}

Policy enforcement patterns — simple scripts to OPA

For larger organizations you should migrate the comparison logic into a policy engine so policies are auditable, reusable, and decoupled from CI implementation. Open Policy Agent (OPA) is a natural fit.

Example Rego policy (conceptual):

package timing.policy

default allow = false

# budgets is injected as input.budgets
# report is in input.report

allow {
  not violations
}

violations {
  some fn
  input.report.wcet[fn] > input.budgets[fn]
}

Invoke OPA in CI:

Run rocqstat to produce JSON.
curl -X POST to opa eval with input { "report": ..., "budgets": ... } and evaluate the policy.
Fail CI when allow == false and post detailed messages to the PR (PR comment or check output).

Blocklist and allowlist strategies

Some functions or modules are more safety-critical and must be treated differently:

Blocklist: A list of high-criticality regions that must always be checked; any failure is non-negotiable.
Allowlist: Functions excluded from the automated check (for example, third-party modules analyzed by a separate process).

Keep these lists in the repo and enforce them via policy so changes to critical regions require explicit review and updated budgets.

Optimizing for CI speed and cost

Full WCET analysis can be expensive. Below are proven strategies to keep CI fast without losing safety.

Incremental analysis: Run full analysis only when critical files change. Start with a fast delta analysis for changed units.
Selective scope: Use git diff to detect which functions/modules changed and only analyze those plus their dependencies.
Cache analysis artifacts: Reuse previously computed results for unchanged modules using a cache key (commit hash of module) stored in an object store.
Deterministic builds: Ensure reproducible builds so results are comparable between runs. For teams setting up verification farms and repeatable pipelines, see IaC templates and examples for automated verification.
Parallelize: Use matrix jobs for multi-target WCET checks and ephemeral runners to scale only when needed. Consider serverless or lightweight runners as discussed in free-tier comparisons of runners and execution environments.

Handling non-determinism & statistical timing

On modern hardware, measured timing can have variance. Instead of single-run comparisons, adopt statistically sound checks:

Run N samples, use median or 95th percentile to compare against budget.
Require statistical confidence (bootstrap or t-tests) before flagging a violation.
For WCET estimation tools like RocqStat, prefer the formal/worst-case estimates where available — then budgets are deterministic.

Traceability, provenance and audits

For safety-critical systems you need more than a pass/fail signal. Produce auditable artifacts:

Store rocqstat.json and the exact binary analyzed as CI artifacts linked to the PR.
Record analysis metadata: tool version, container digest, input commit SHA.
Attach SLSA-style provenance or sign the artifact with a build key to prevent tampering.

Advanced GitOps patterns: pre-merge + pre-sync double gate

For maximum safety, use a two-layer gate:

Pre-merge gate (CI): Blocks merges that fail timing checks — the fastest and most developer-friendly gate.
Pre-sync gate (GitOps controller): After merge, an ArgoCD pre-sync hook or admission controller verifies that the merged commit includes a valid timing attestation and prevents deployment if missing or invalid.

This pattern keeps the Git repo clean and ensures that external changes (e.g., hotfixes applied outside the pipeline) are also validated before deployment.

Example: integrating with ArgoCD (concept)

ArgoCD supports pre-sync hooks. Use a hook that fetches the timing attestation artifact (created by CI) and verifies it with OPA. If the attestation fails, the hook exits non-zero and ArgoCD aborts the sync. For broader architecture guidance and controller-level defenses, see work on resilient cloud-native architectures.

Case study (fictional, actionable takeaways)

AutonomySoft maintained a vehicle-control stack where a minor refactor introduced a 30% regression in a scheduler function. Before integrating RocqStat into PR checks, regressions slipped through to preprod and caused two costly rollbacks. After implementing the CI pattern above, they observed:

100% reduction in regressions reaching preprod for timing budgets tracked.
Median PR iteration time reduced by 22% because developers got immediate feedback.
Audit readiness improved: every merge now included a signed timing report linked to the PR.

Checklist — getting started in your repo (15 60 minutes to initial value)

Add a budgets.json to your repo and document how budgets are calculated.
Prepare a container image that includes RocqStat and your build toolchain.
Commit a GitHub Actions/GitLab CI workflow that runs RocqStat and fails on budget violations.
Post results to the PR and upload ROCQ artifacts to the CI artifact store.
Add branch protection rules to block merging when the timing check fails.
Later: migrate checks into OPA and add a pre-sync ArgoCD hook for defense-in-depth.

2026 trends & forward-looking recommendations

Expect the following in 2026 and beyond:

Vendors will ship timing analysis as integrated services inside broader verification suites (see Vector & RocqStat acquisition) — this simplifies enterprise adoption.
Policy-as-code and supply-chain provenance (SLSA-level attestations) will be required by many regulated industries as part of verification pipelines.
Tooling will offer more incremental and differential timing analysis to make continuous checks cost-effective.

Recommendation: start with a lightweight CI-based RocqStat check for changed units, capture artifacts and budgets in the repo, and iterate toward policy-driven enforcement and pre-sync hooks. This staged approach provides early safety gains without a heavy upfront engineering cost.

Vector's move to integrate RocqStat into its toolchain is a signal: timing safety is now core to software verification workflows — make it core to your GitOps strategy too.

Final thoughts

Timing violations are predictable and preventable when you treat timing analysis as a first-class automated check in GitOps. By running RocqStat (or similar tools) as part of premerge checks and enforcing results through policy, you reduce production incidents, shorten feedback loops, and create an auditable trail for compliance.

Actionable next step: Copy the example workflow into a branch today, add a budgets.json file, and run a smoke RocqStat job on a representative unit. If you want a hands-on workshop or a ready-made action image, reach out to your tool vendor or build a minimal container from your RocqStat license and try the flow on a small PR. For examples of infrastructure-as-code and verification automation patterns that accelerate this work, see templates for automated verification and embedded test farms.

Call to action

Ready to stop timing regressions at the PR level? Clone our example repository, drop in your RocqStat container, and enable the workflow. If you want help designing a policy-as-code strategy or integrating a pre-sync ArgoCD gate, contact us for a hands-on design session tailored to your GitOps environment.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.