iPolloWork Docs

Desktop packaging

Build, verify, and package the Electron client without confusing local artifacts with a published release.

iPolloWork has three build levels. Choose the least expensive command that proves what you need.

System flowDesktop release path

The project keeps build, local verification, and publish-oriented release work as separate steps.

  1. 01Build

    Compile UI, server, Electron shell, and sidecars.

  2. 02Verify

    Use an unpacked desktop app for fast local validation.

  3. 03Package

    Create native installer and portable artifacts for this machine.

  4. 04Release matrix

    Use the GitHub release flow for signed multi-platform delivery.

CommandResult
./ipollowork buildProduction UI, server, Electron shell, and sidecars. No installer.
./ipollowork package:dirFast unpacked local desktop app for verification.
./ipollowork packageChecks, version advancement, and native installer artifacts for the host system.
Release ownershipBuild output, local package, and published release are different deliverables

Choose the smallest artifact that proves the current change. Do not describe a local unsigned installer as a public, signed release.

01
Repository checks

Source correctness

Launcher check

Runs the project verification contract for the checked-out revision.

Build output

Proves application packages compile; it does not prove an installer can install.

02
Local artifact

Host-specific validation

Unpacked app

`package:dir` creates a fast executable validation artifact for the current machine.

Native installer

`package` creates installer or portable outputs for the current OS and CPU.

03
Release delivery

Distribution responsibility

Signing and notarization

Requires the relevant platform identity and release workflow.

Published matrix

Multi-platform delivery must be built and verified for each supported platform.

./ipollowork check
./ipollowork package:dir
./ipollowork package

On Windows, use .\ipollowork.cmd.

All outputs are written to apps/desktop/dist-electron/. The local package targets the current operating system and CPU only. It is not a substitute for the published GitHub release workflow, which produces the full signed or notarized platform matrix.

Expected local artifacts

  • macOS: .dmg, .zip, and an unpacked .app
  • Windows: NSIS .exe and win-unpacked/
  • Linux: .AppImage, .tar.gz, and linux-unpacked/

Local packages are unsigned unless the relevant Apple or Windows credentials are supplied. They are appropriate for internal verification, not an implied official release.

Verify the artifact you actually made

After package:dir, open the unpacked desktop application and exercise the changed workflow through the real local runtime. This is the fastest path for a UI, preload, local-server, or sidecar integration change. After package, verify the install or launch path appropriate to the host operating system and ensure the packaged application—not the development server—loads the expected version.

Keep the checks ordered:

  1. Run ./ipollowork check on the target revision.
  2. Produce package:dir and validate the focused desktop path.
  3. Produce package only when an installer or host-native release artifact needs validation.
  4. Record operating system, CPU architecture, artifact name, and whether signing/notarization was applied.
  5. Use the repository release workflow for the signed multi-platform matrix; do not hand-assemble that matrix on one arbitrary workstation.

If the problem is runtime assembly rather than Electron packaging, use Orchestrator and sandbox. For full release evidence and recovery, use Observability and recovery.