# pear-git CI — build an installable Blender zip on push.
#
# Note this repo does NOT end in `pgh publish .` like the bare apps do. Two
# different systems share the name "release":
#
# pgh publish . -> pgh-sidecar's ReleaseRegistry. Content-addresses the tree
# for `pgh app install`. Produces metadata only — never a file.
# this ci.yaml -> the forge's build-release. Whatever is listed under
# `artifacts:` lands on /git/repos/hardops/releases as a
# download.
#
# A downloadable addon zip only comes from the second one, so it is built here.
#
# The zip has a single top-level `hardops/` directory holding
# blender_manifest.toml, which is the layout Blender's "Install from Disk"
# expects (the vendor zip ships the same shape as `HOps/`).
steps:
- name: build blender zip
run: |
set -e
mkdir -p build/hardops
# copy the tree minus VCS, bytecode and the build dir itself
tar cf - --exclude=./.git --exclude=__pycache__ --exclude=./build . \
| (cd build/hardops && tar xf -)
# Reproducible zip. Artifacts do NOT replicate between forge backends —
# each daemon builds its own from the same commit — so a naive `zip -r`
# yields the same SIZE but a different HASH on each backend, because it
# stores checkout mtimes and readdir order. Behind the load balancer that
# makes /releases/<repo>/<version>/<file> return different bytes depending
# on which backend answers, and any checksum a user records is
# backend-specific.
#
# Pinning mtimes to the commit timestamp, sorting entries, and -X
# (drop extra file attributes) makes independent builds of one commit
# byte-identical, so the URL is a stable identifier again.
TS=$(git log -1 --format=%ct 2>/dev/null || echo 0)
cd build
find hardops -exec touch -h -d "@$TS" {} +
find hardops -print | LC_ALL=C sort | zip -X -q ../hardops.zip -@
cd ..
ls -l hardops.zip
sha256sum hardops.zip
timeout: 300
artifacts:
- hardops.zip