zkbuild-action vs. zkmake
Part of the DevTools overview pipeline — this page helps you choose between the cloud action and the on-premises CLI for build and test.
Both tools compile TwinCAT PLC projects, install Twinpack packages, and run unit tests automatically. The difference is where they run and what infrastructure they require.
Feature comparison
| zkbuild-action (cloud) | zkmake (on-premises) | |
|---|---|---|
| Infrastructure | Zeugwerk CI/CD - no setup required | Your own Windows build server |
| TwinCAT XAE required | No | Yes - must be installed on the build machine |
| OS | Ubuntu runner (managed) | Windows only |
| Pipeline support | GitHub Actions, GitLab CI, Bitbucket Pipelines | Any CI that can run a Windows .exe (Jenkins, Azure DevOps, TeamCity, …) |
| Private repositories | Commercial plan | License required |
| Free tier | 30 builds/month for public repositories | - |
| Patches | Platform patches + argument patches | Platform patches + argument patches |
| Config format | .Zeugwerk/config.json |
.Zeugwerk/config.json (identical) |
| Installer generation | Yes (installer: true input) |
No (pipeline responsibility) |
| Variant builds | Yes (variant-build / variant-test inputs) |
Yes (--variant-build / --variant-test flags) |
| Static analysis | Yes (static-analysis input) |
Yes (--static-analysis flag) |
Artifacts
Both tools run the same build-and-test pipeline (Twinpack restore → patches → compile → test). zkmake is the on-premises orchestrator: it executes that pipeline on your Windows agent and writes outputs to the working tree. zkbuild-action wraps the same engine on managed infrastructure and additionally collects compliance and audit artifacts automatically.
Build outputs (both tools)
| Artifact | zkbuild-action path | zkmake path | Condition |
|---|---|---|---|
| Compiled library | archive/libraries/<tcversion>/<Name>_<Version>.library |
.Zeugwerk/libraries/<tcversion>/<Name>_<Version>.library |
PLC type is Library or FrameworkLibrary |
| Unit test results (JUnit XML) | archive/test/TcUnit_xUnit_results.xml (embedded / tests/) · archive/tests/<TestProjectFolder>/TcUnit_xUnit_results.xml (in-solution) |
tests\TcUnit_xUnit_results.xml (embedded / tests/) · tests\<TestProjectFolder>\TcUnit_xUnit_results.xml (in-solution) |
When tests are not skipped |
| Static analysis results (Checkstyle XML) | archive/*-checkstyle-result.xml |
*-checkstyle-result.xml |
When static analysis is enabled |
Installer (.exe) |
archive/<Name> <Version>.exe |
- | When installer: true. See zkbuild-action — PLC deployment installer. |
Pipeline artifacts (zkbuild-action only)
zkbuild-action archives additional files alongside the build outputs for traceability and compliance. These are produced by the pipeline, not by zkmake itself:
| Artifact | Path | Description |
|---|---|---|
| Build references | archive/references.json |
Project name, version, branch, and commit SHAs |
Merged config.json |
archive/config.json |
The resolved project configuration used for this build |
| Build log | archive/build-output.log |
Output of the compile and test step |
| Console log | archive/console.log |
Full pipeline log for audit trails |
| Build node fingerprint | archive/buildnode-fingerprint.log |
OS, CPU, disk, drivers, and active processes at build time - retained for compliance audits |
When to use zkbuild-action
- Your source code is hosted on GitHub, GitLab, or Bitbucket.
- You want zero build-server maintenance.
- Your project is open-source or you are happy with the commercial cloud plan.
- You want the simplest possible setup: add a workflow file and push.
When to use zkmake
- Your code or build artifacts must stay inside your own network (air-gapped, compliance, IP protection).
- You already run an on-premises CI/CD system (Jenkins, Azure DevOps, TeamCity, etc.) and want to keep everything there.
- You need a Git host that is not GitHub, GitLab, or Bitbucket.
- You want full control over the TwinCAT version and machine configuration.
Using both together
The two tools share the same .Zeugwerk/config.json format, so you can switch between them or use them in parallel without changing your project configuration. A common pattern is to use zkbuild-action for open-source or team preview builds and zkmake for release builds on a controlled build server.