Skip to main content

Overview

Run driverforge in your pipeline to build and ship your Control4 drivers automatically on every push, tag, or release. Two integrations wrap the same CLI:

  • GitHub Action: driverforge/driverforge-github-action, for GitHub Actions workflows.
  • Buildkite plugin: driverforge/driverforge-buildkite-plugin, for Buildkite pipelines.

On anything else, run the CLI directly — it is a self-contained binary, so installing it is a few lines of shell. GitLab CI/CD has a worked template you can adapt to any runner.

Preview

The driverforge GitHub Action and Buildkite plugin are available today and in preview: while the CLI is pre-1.0, the interfaces may still evolve between releases. Pin your versions, and follow along or vote on our roadmap.

How they work​

Both integrations follow the same model: they install a pinned driverforge release onto the runner and put it on PATH, then optionally run a command for you. That gives you two ways to use them.

Just set up the environment​

Omit the command and the integration simply makes driverforge available, so you can call it however you like from your own scripts (the actions/setup-node pattern):

# GitHub Actions
- uses: driverforge/driverforge-github-action@v1
with:
version: '0.1.0'
- run: driverforge build -c release

Run a target directly​

Give it a command and it runs that target in a single declarative step (no extra scripting):

# GitHub Actions
- uses: driverforge/driverforge-github-action@v1
with:
command: build
configuration: release

What you need​

Nothing extra on the runner. driverforge is a self-contained native binary, so the integration downloads the pinned release, verifies its checksum, and adds it to PATH: no Lua, LuaRocks, or container image required.

We recommend pinning a version (rather than latest) so a new release can't change your build without you choosing to upgrade.

Coming from driverpackager?​

If you currently package drivers with the snap-one/drivers-driverpackager action, see Migrating from driverpackager for the input-by-input mapping.