zb-release-pipeline

Name: zb-release-pipeline
Author: AdamBien

40stars10forks

How to install zb-release-pipeline?

adambien/airails/zb-release-pipeline

$npx -y skills add AdamBien/airails --skill zb-release-pipeline

Installs into the current project.

Summary

Generate a GitHub Actions pipeline that builds a zb (Zero Dependencies Builder) project and publishes a GitHub Release with the produced JAR. Use whenever the user wants CI/CD, a build pipeline, a release workflow, or GitHub Actions for a zb-based Java project — phrases like "set

Files · 1

View on GitHub

SKILL.md

1	# zb GitHub Actions Pipeline
2
3	Generate `.github/workflows/release.yml` for a zb project. The pipeline checks out the
4	repo, installs Java, reads the project version, downloads the latest `zb.jar`, builds the
5	project, and creates a GitHub Release with the produced JAR attached and tagged
6	`v<version>.<run_number>`.
7
8	This skill produces a workflow equivalent to the reference below — only with the
9	project-specific paths and names auto-detected, nothing hardcoded:
10
11	```yaml
12	- name: Build
13	working-directory: <module>
14	run: java -jar ../zb.jar
15	- name: Create Release
16	run: gh release create "v${{ steps.version.outputs.version }}.${{ github.run_number }}" ...
17	```
18
19	## Procedure
20
21	### 1. Locate the build directory
22
23	The build directory is where zb runs from — the directory that contains the project's
24	`.zb` config alongside the sources (`src/main/java` or `src/`).
25
26	- Glob for `.zb` files in the repository.
27	- If a repo has both a root `.zb` and a `.zb` in a module subdirectory, the **build
28	directory is the one that also contains `version.txt` and the actual `src/` tree**.
29	A multi-module-style layout (e.g. `zsmith/zsmith/`) builds from the inner module.
30	- Record `BUILD_DIR` as the path relative to the repository root. If the build directory
31	is the repo root, `BUILD_DIR` is `.`.
32
33	### 2. Read the `.zb` config in the build directory
34
35	From the build directory's `.zb`, extract:
36
37	- `jar.file.name` (e.g. `zsmith.jar`) → this is the artifact file name.
38	- `jar.dir` (e.g. `zbo/`) → defaults to `zbo/` if absent.
39
40	Derive:
41
42	- `ARTIFACT_NAME` = `jar.file.name` without the `.jar` suffix (used in the release title).
43	- `ARTIFACT_PATH` = `<BUILD_DIR>/<jar.dir><jar.file.name>`, normalized (no `./` prefix,
44	collapse `//`). Example: `zsmith/zbo/zsmith.jar`.
45
46	### 3. Resolve the version file
47
48	The version step does `cat <VERSION_FILE>` at the repo root.
49
50	- Look for `version.txt` in the build directory first, then the repo root.
51	- `VERSION_FILE` = that file's path relative to the repo root (e.g. `zsmith/version.txt`
52	or `version.txt`).
53	- If no `version.txt` exists anywhere, tell the user one is required for the release tag
54	and offer to create one (single line, e.g. `1.0.0`) in the build directory. Do not
55	invent a different versioning scheme.
56
57	### 4. Compute the zb.jar reference
58
59	`zb.jar` is downloaded to the repository root. The Build step runs with
60	`working-directory: <BUILD_DIR>`, so the `java -jar` argument is the relative path from
61	the build directory back up to the root:
62
63	- `BUILD_DIR` is `.` (repo root) → `ZB_JAR_REF` = `zb.jar`
64	- `BUILD_DIR` is one level deep (e.g. `zsmith`) → `ZB_JAR_REF` = `../zb.jar`
65	- `n` levels deep → `n` repetitions of `../` then `zb.jar`
66
67	### 5. Java version
68
69	Default to `25` (matches the zb / Java 21+ requirement and the reference workflow). If the
70	project's `.zb` or build config pins a different release/source level, use that instead.
71	If unsure, ask the user; do not silently downgrade.
72
73	### 6. Generate the workflow
74
75	Read `assets/release.yml` (the template) and substitute:
76
77	\| Placeholder \| Value \|
78	\|---------------------\|----------------------------------------------------\|
79	\| `__JAVA_VERSION__` \| resolved Java version (e.g. `25`) \|
80	\| `__VERSION_FILE__` \| `VERSION_FILE` \|
81	\| `__BUILD_DIR__` \| `BUILD_DIR` \|
82	\| `__ZB_JAR_REF__` \| `ZB_JAR_REF` \|
83	\| `__ARTIFACT_PATH__` \| `ARTIFACT_PATH` \|
84	\| `__ARTIFACT_NAME__` \| `ARTIFACT_NAME` \|
85
86	If `BUILD_DIR` is `.`, drop the `working-directory:` line entirely (a `working-directory`
87	of `.` is noise) rather than emitting `working-directory: .`.
88
89	Write the result to `.github/workflows/release.yml` in the repository root. Create
90	`.github/workflows/` if it does not exist. If `release.yml` already exists, show the diff
91	and confirm before overwriting.
92
93	### 7. Report
94
95	Summarize for the user:
96
97	- Detected build directory, artifact path, version file, Java version.
98	- The trigger: every push to `main` and manual `workflow_dispatch`.
99	- The release tag scheme: `v<version>.<github.run_number>`.
100	- Reminder that the workflow needs no extra secrets — it uses

People who liked this also viewed

6 picks

Type

zb-release-pipeline

40stars10forks

View on GitHub

How to install zb-release-pipeline?

adambien/airails/zb-release-pipeline

$npx -y skills add AdamBien/airails --skill zb-release-pipeline

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# zb GitHub Actions Pipeline
2
3	Generate `.github/workflows/release.yml` for a zb project. The pipeline checks out the
4	repo, installs Java, reads the project version, downloads the latest `zb.jar`, builds the
5	project, and creates a GitHub Release with the produced JAR attached and tagged
6	`v<version>.<run_number>`.
7
8	This skill produces a workflow equivalent to the reference below — only with the
9	project-specific paths and names auto-detected, nothing hardcoded:
10
11	```yaml
12	- name: Build
13	working-directory: <module>
14	run: java -jar ../zb.jar
15	- name: Create Release
16	run: gh release create "v${{ steps.version.outputs.version }}.${{ github.run_number }}" ...
17	```
18
19	## Procedure
20
21	### 1. Locate the build directory
22
23	The build directory is where zb runs from — the directory that contains the project's
24	`.zb` config alongside the sources (`src/main/java` or `src/`).
25
26	- Glob for `.zb` files in the repository.
27	- If a repo has both a root `.zb` and a `.zb` in a module subdirectory, the **build
28	directory is the one that also contains `version.txt` and the actual `src/` tree**.
29	A multi-module-style layout (e.g. `zsmith/zsmith/`) builds from the inner module.
30	- Record `BUILD_DIR` as the path relative to the repository root. If the build directory
31	is the repo root, `BUILD_DIR` is `.`.
32
33	### 2. Read the `.zb` config in the build directory
34
35	From the build directory's `.zb`, extract:
36
37	- `jar.file.name` (e.g. `zsmith.jar`) → this is the artifact file name.
38	- `jar.dir` (e.g. `zbo/`) → defaults to `zbo/` if absent.
39
40	Derive:
41
42	- `ARTIFACT_NAME` = `jar.file.name` without the `.jar` suffix (used in the release title).
43	- `ARTIFACT_PATH` = `<BUILD_DIR>/<jar.dir><jar.file.name>`, normalized (no `./` prefix,
44	collapse `//`). Example: `zsmith/zbo/zsmith.jar`.
45
46	### 3. Resolve the version file
47
48	The version step does `cat <VERSION_FILE>` at the repo root.
49
50	- Look for `version.txt` in the build directory first, then the repo root.
51	- `VERSION_FILE` = that file's path relative to the repo root (e.g. `zsmith/version.txt`
52	or `version.txt`).
53	- If no `version.txt` exists anywhere, tell the user one is required for the release tag
54	and offer to create one (single line, e.g. `1.0.0`) in the build directory. Do not
55	invent a different versioning scheme.
56
57	### 4. Compute the zb.jar reference
58
59	`zb.jar` is downloaded to the repository root. The Build step runs with
60	`working-directory: <BUILD_DIR>`, so the `java -jar` argument is the relative path from
61	the build directory back up to the root:
62
63	- `BUILD_DIR` is `.` (repo root) → `ZB_JAR_REF` = `zb.jar`
64	- `BUILD_DIR` is one level deep (e.g. `zsmith`) → `ZB_JAR_REF` = `../zb.jar`
65	- `n` levels deep → `n` repetitions of `../` then `zb.jar`
66
67	### 5. Java version
68
69	Default to `25` (matches the zb / Java 21+ requirement and the reference workflow). If the
70	project's `.zb` or build config pins a different release/source level, use that instead.
71	If unsure, ask the user; do not silently downgrade.
72
73	### 6. Generate the workflow
74
75	Read `assets/release.yml` (the template) and substitute:
76
77	\| Placeholder \| Value \|
78	\|---------------------\|----------------------------------------------------\|
79	\| `__JAVA_VERSION__` \| resolved Java version (e.g. `25`) \|
80	\| `__VERSION_FILE__` \| `VERSION_FILE` \|
81	\| `__BUILD_DIR__` \| `BUILD_DIR` \|
82	\| `__ZB_JAR_REF__` \| `ZB_JAR_REF` \|
83	\| `__ARTIFACT_PATH__` \| `ARTIFACT_PATH` \|
84	\| `__ARTIFACT_NAME__` \| `ARTIFACT_NAME` \|
85
86	If `BUILD_DIR` is `.`, drop the `working-directory:` line entirely (a `working-directory`
87	of `.` is noise) rather than emitting `working-directory: .`.
88
89	Write the result to `.github/workflows/release.yml` in the repository root. Create
90	`.github/workflows/` if it does not exist. If `release.yml` already exists, show the diff
91	and confirm before overwriting.
92
93	### 7. Report
94
95	Summarize for the user:
96
97	- Detected build directory, artifact path, version file, Java version.
98	- The trigger: every push to `main` and manual `workflow_dispatch`.
99	- The release tag scheme: `v<version>.<github.run_number>`.
100	- Reminder that the workflow needs no extra secrets — it uses

People who liked this also viewed

6 picks

Type