Release NSIS packages from GitHub: plugins built from source, or headers, graphics and language files with nothing to build.

Build on every push. When a release is published, attach these files to it:

• a Release Archive
• a Package Installer
• checksums, and build attestations on request

on:
  push:
  pull_request:
  release:
    types: [published]

jobs:
  plugin:
    runs-on: windows-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v7
      - uses: nsis-dev/release-package@v0
        with:
          name: Hello
          sources: Contrib/Hello/*.c

A repository with nothing to build (headers, graphics, language files) sets neither sources nor project, only name.

A plugin whose source is lost can set toolchain: prebuilt and commit Plugins/<target>/<name>.dll instead. This is an antipattern and the action warns about it: nobody can rebuild or verify those DLLs, and an attestation only proves the workflow copied them. Use it only to keep an otherwise abandoned plugin available.

A release of tag v1.0.0 gets these assets:

Other builds upload the zip and installer as the workflow artifact <name>-<toolchain>, versioned by the short commit SHA. To attest build provenance, set attestations: true and add the id-token: write and attestations: write permissions. Attestations are free on public repositories; a private one needs GitHub Team or Enterprise. Check where a released file came from with gh attestation verify Hello-1.0.0.zip --repo <owner>/<repo>.

To also build with a second Toolchain as a check, use a matrix and release only one of them:

jobs:
  plugin:
    strategy:
      matrix:
        include:
          - { toolchain: msvc, os: windows-latest, release: true }
          - { toolchain: mingw, os: ubuntu-latest, release: false }
    runs-on: ${{ matrix.os }}
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v7
      - uses: nsis-dev/release-package@v0
        with:
          name: Hello
          sources: Contrib/Hello/*.c
          toolchain: ${{ matrix.toolchain }}
          release: ${{ matrix.release }}

A Package repository is laid out like NSISDIR, as specified in SPEC.md for other tools to implement. The action checks this first and fails before building if it isn't:

Contrib, Docs, Examples, Include and Plugins must be spelled that way.

The build runs as if the repository were the NSIS source tree: before compiling, the action puts the plugin API at Contrib/ExDLL/ (pluginapi.h, pluginapi.c, nsis_tchar.h, nsis.pas) and Source/exehead/api.h, so includes like "../ExDLL/pluginapi.h" resolve. Don't commit those folders; the layout check fails if you do. #include "pluginapi.h" and <nsis/pluginapi.h> work too.

Each Toolchain takes exactly one of sources and project; the action fails before building if the other one is set. List inputs are comma or newline separated, so paths may contain spaces.

There are deliberately no inputs for defines, libraries, include directories or raw flags:

• Every directory holding a matched source is an include directory.
• A fixed list of common Windows import libraries is linked; unused ones add no imports. If a Plugin needs one that's missing, open an issue.
• Put defines in a header.
• The NSIS version of the Plugin API, the Free Pascal version and the Zig version are pinned, and only change in a release release.

Include the Plugin API the way NSIS installs it:

#include <windows.h>
#include <nsis/pluginapi.h>

pluginapi.c is compiled in. UNICODE and _UNICODE are defined for *-unicode targets. A C++ plugin needs extern "C" on its exported functions.

The C/C++ Toolchains differ in which C runtime a crt: static Plugin depends on:

With crt: none no Toolchain imports a C runtime. zig then leaves uuid out of the linked libraries, so a Plugin using COM GUIDs such as IID_IUnknown defines them itself with INITGUID.

Use the unit NSIS ships:

library Hello;

uses
  nsis, Windows;

procedure Greet(const hwndParent: HWND; const string_size: integer; const variables: NSISPTChar; const stacktop: pointer); cdecl;
begin
  Init(hwndParent, string_size, variables, stacktop);
  PushString('Hello, ' + PopString() + '!');
end;

exports
  Greet;

begin
end.

Code compiles in Delphi mode (-Mdelphi) unless the source sets {$mode}. UNICODE is defined for *-unicode targets, which switches nsis.pas to wide strings. The official Free Pascal installer is downloaded from SourceForge, checked against the MD5 listed there, and cached.

Keep the crate in Contrib/<name>/, or put a workspace Cargo.toml at the top level with Contrib/<name> as a member, and point project at the Plugin's own Cargo.toml. The action builds it with Cargo for the *-pc-windows-msvc targets and relies on two things only:

• [lib] crate-type = ["cdylib"]. The DLL is renamed to <name>.dll, so the crate name doesn't have to match.
• *-unicode targets build the crate's default features. x86-ansi builds with --no-default-features --features ansi, so a crate that builds x86-ansi needs an ansi feature that switches it to ANSI strings.

Export functions as #[unsafe(no_mangle)] pub extern "C" fn. No Plugin API is supplied; bring a crate for it or write the stack handling yourself. A rust-toolchain.toml next to the manifest picks the Rust version, otherwise the runner's stable Rust is used. Size settings such as opt-level, lto and panic = "abort" belong in the crate's [profile.release].

mise installs the tools (Python, ruff, actionlint, hk) and the hk pre-commit hook:

mise install
mise run check   # lint, formatting, script self-check
mise run fix     # apply lint and formatting fixes

action.yml runs stdlib-only Python scripts from scripts/, which also run locally:

NAME=HelloC SOURCES='test/hello/Contrib/HelloC/*.c' TOOLCHAIN=mingw python3 scripts/build_c.py build

Apache License, Version 2.0