Driver build and release architecture

flowchart LR
  Matrix[customers.json] --> Fanout[release-all-customers]
  Manual[Manual dispatch] --> Release[release-driver]
  Fanout --> Release
  Release --> Resolve[Resolve niseCore / WBF / include SHAs]
  Resolve --> Change{Relevant SHA changed?}
  Change -->|yes| Build[build-driver reusable workflow]
  Build --> Action[Build action at pinned automation ref]
  Action --> Source[Checkout selected source refs]
  Source --> Compile[EWDK compile + package]
  Compile --> Validate[Tests / package validation]
  Validate --> Sign[Signing service]
  Sign --> Artifact[Build artifact]
  Artifact --> GHRelease[GitHub release]
  GHRelease --> History[Release-history record]
  Fanout --> Reconcile[Reconcile missing history rows]
  Reconcile --> History

Boundaries

Component	Source	Architectural responsibility
Customer matrix	.github/customers.json	Selects customer project, niseCore/WBF/include refs, EWDK, method and target.
Build workflow	.github/workflows/build-driver.yml	Dispatches the reusable build action with explicit inputs and protected secrets.
Release workflow	.github/workflows/release-driver.yml	Resolves exact SHAs, detects changes, builds, caches, packages, releases and records evidence.
All-customer orchestrator	.github/workflows/release-all-customers.yml	Fans out one release per matrix row and reconciles missing release-history updates.
Signing/publishing	Sign/, Pipeline_SynaSign*.bat, SynaSignService/	Supports package signing and publication paths; secret material must remain external.
Validation	AccuracySuiteValidation/, AutoHLK/, BlackDuck/	Provides accuracy, HLK and security/compliance pipeline assets.
Legacy/Jenkins pipelines	Pipeline_.bat, niseBuild.cmd	Retains legacy build/deploy flows alongside GitHub Actions.
Tuning/tools	AutoFRRTuning/, IPLTuning/, QMAutoTrain/, FPCollection/	Provides tuning, scoring, collection and analysis tooling outside the core driver build.

Change-safety rules

• Follow calls and data across component boundaries; a changed header or customer property can affect multiple binaries.
• Keep source revision and branch explicit because configured branches differ substantially.
• Validate both the component and its direct consumers.
• Treat optional/customer-selected components as conditional, not universally deployed.