Automation does not start with a CI server. It starts with a command that runs the same checks from a defined source revision and reliably reports whether they succeeded. Integrating it into a pipeline is worthwhile only once that process works in a fresh working directory.
Define the contract for a test run
Specify inputs and outputs explicitly. Inputs include source files, file order, libraries, language versions, tool versions and licence prerequisites. Outputs include a process status, an understandable log and, where needed, reports or waveforms. Temporary working libraries belong in a separate build directory.
Failures must remain visible
A script must not report success merely because a log file exists. A compiler error, missing licence, failed assertion or timeout must terminate execution and produce a failure status. Test these paths deliberately. A pipeline result is only as trustworthy as the error handling in the invoked tool and its wrapper.
Keep editor, compiler and CI in sync
Use a common project description wherever possible. Current Sigasi documentation describes Modular Projects and tasks for external compilers. A dedicated task type is documented for Riviera-PRO. This improves feedback in the editor; a full simulation still requires its own step. The workflow explains that boundary.
A practical sequence
- Build and run a small test locally using a script.
- Check dependencies in a fresh checkout.
- Trigger a failure deliberately and inspect the exit code.
- Define timeouts and result retention.
- Only then schedule runs for selected changes or regular regressions.
ALINT-PRO documents batch and Tcl workflows for static checks. For simulator runs, the number of concurrently available licences must also fit the execution model. Parallelising without clarifying this simply moves the bottleneck to the licence queue.
The regression application notes provide a concrete structure. A technical consultation can help assess the operating system, runners, licence access and result criteria together.