pdulvp.fr

prel build, and releaseBuildCommand as the key it is now has been fixed.

See more details at : https://github.com/pdulvp/prel/issues/9

and by nothing else, and the name now says which build it configures

  • a config still setting buildCommand is warned about by name, with the name

to rename it to - the generic unknown-key warning would let a release go out
with no build at all

from the repository root with $version and $tag, so a build gets tried
before a release depends on it - no commit, no tag, no push, and the build's
own exit status

expanded; the build step of prel release goes through it

  • prel config widens its label column to fit the longer key

buildCommand becomes releaseBuildCommand

<sub>2026-10-22-1620-release-build-command.md — 2026-10-22 16:20</sub>

Goal

The prel.config.json key buildCommand is read by prel release and by
nothing else. The name says a build; the key is about one build in particular,
the one that makes the files a release carries. Rename it
releaseBuildCommand, so a repository's config says which build it is
configuring.

{
  "releaseBuildCommand": "packaging/build-deb.sh ${version}",
  "artifacts": ["build/prel_${version}_all.deb"]
}

Decisions

$build_command local keep their names: they already live in release.sh,
where every name is about a release.

  • An old buildCommand is named rather than caught by the generic unknown

key warning: the generic one says "prel does not read this" and lets the
release run with no build, which is the quiet failure the config check
exists to prevent. Same treatment as the stale prel.* git config keys -
warned about, with the new name to move it to, never obeyed.

config key actually had, and the warning tells the reader where it went -
now to releaseBuildCommand rather than to its own name.

is 20 characters, and the five labels stay in one column.

Steps

warning in _prel_config_check, the git-key warning pointing at the new
name, the %-13s widths, and the config usage text

release usage text, the dry-run line

prel.buildCommand

sample output, the release-artifacts section, the .deb section, the
configuration-files list

  • [x] test: prel config on the new key, on a config still holding

buildCommand, and with a prel.buildCommand git config key set

artifacts` still resolves

archive this file

prel build: the release build, run on its own

<sub>2026-10-22-1845-prel-build.md — 2026-10-22 19:10</sub>

Goal

releaseBuildCommand can only be run by prel release, which tags and pushes
around it. A project setting it has no way to try it: the first time the
command runs is the release, and a build that fails there undoes a commit and
a tag to get back. prel build runs that command and nothing else - same
directory, same $version and $tag, no commit, no tag, no push.

$ prel build
build:     packaging/build-deb.sh ${version}
version:   0.2.3 (from VERSION)
tag:       v0.2.3
...
prel build: the build succeeded

Decisions

scripts/*.sh into a command, and the whole file name is the command, so no
shortcut alias is needed.

  • The version comes from versionFile as it reads now, or from an argument:

prel build 1.0.1, the same shape prel release artifacts takes. No
version to be had is an error naming the argument, not a build run with an
empty ${version} - the one in prel's own config would call
build-deb.sh with no version at all.

  • The build sees $version and $tag as shell variables, which is what

"packaging/build-deb.sh ${version}" relies on, and runs from the
repository root. That contract is documented, so it gets one
implementation: _prel_build_eval in build.sh, which release.sh calls
in place of its own cd-and-eval subshell.

  • The exit status is the build's own, so a script can gate on it. With

artifacts set, what the patterns match is printed after a build that
worked - as a report, not a verdict: prel release artifacts is the command
that exits non-zero over a pattern matching nothing, and is named here.

  • -n/--dry-run prints the command, the version and the tag and runs

nothing, as prel release -n does.

ordinary case for most projects, said plainly with the key to set, and
exits 0.

Found on the way

locals of the function the eval sat in. _prel_build_eval takes the two
as arguments and declares them itself, so what a build command can read is
stated where it is run rather than inherited from whoever calls it.

Steps

build command with its usage

build.sh in the direct-run block as it does config.sh

release-artifacts section pointing at it, and the direct-script list

  • [x] test: prel build in this repository (builds the .deb), -n, an

explicit version, a bad version, a repository with no
releaseBuildCommand, one with no version file, a build command that
fails, and prel build usage

behave - release.sh run directly as well, where it loads build.sh
itself

archive this file

<sub>Filed by prel from the completed plans at commit time.</sub>