zb-release-pipeline

zb GitHub Actions Pipeline

Generate .github/workflows/release.yml for a zb project. The pipeline checks out the repo, installs Java, reads the project version, downloads the latest zb.jar, builds the project, and creates a GitHub Release with the produced JAR attached and tagged v<version>.<run_number>.

This skill produces a workflow equivalent to the reference below — only with the project-specific paths and names auto-detected, nothing hardcoded:

- name: Build
  working-directory: <module>
  run: java -jar ../zb.jar
- name: Create Release
  run: gh release create "v${{ steps.version.outputs.version }}.${{ github.run_number }}" ...

Procedure

1. Locate the build directory

The build directory is where zb runs from — the directory that contains the project's .zb config alongside the sources (src/main/java or src/).

• Glob for .zb files in the repository.
• If a repo has both a root .zb and a .zb in a module subdirectory, the build directory is the one that also contains version.txt and the actual src/ tree. A multi-module-style layout (e.g. zsmith/zsmith/) builds from the inner module.
• Record BUILD_DIR as the path relative to the repository root. If the build directory is the repo root, BUILD_DIR is ..

2. Read the .zb config in the build directory

From the build directory's .zb, extract:

• jar.file.name (e.g. zsmith.jar) → this is the artifact file name.
• jar.dir (e.g. zbo/) → defaults to zbo/ if absent.

Derive:

• ARTIFACT_NAME = jar.file.name without the .jar suffix (used in the release title).
• ARTIFACT_PATH = <BUILD_DIR>/<jar.dir><jar.file.name>, normalized (no ./ prefix, collapse //). Example: zsmith/zbo/zsmith.jar.

3. Resolve the version file

The version step does cat <VERSION_FILE> at the repo root.

• Look for version.txt in the build directory first, then the repo root.
• VERSION_FILE = that file's path relative to the repo root (e.g. zsmith/version.txt or version.txt).
• If no version.txt exists anywhere, tell the user one is required for the release tag and offer to create one (single line, e.g. 1.0.0) in the build directory. Do not invent a different versioning scheme.