BuildPilot v1.2.1

Release notes

Tabs in output no longer show as boxes

A line of output holding a tab showed a small box in its place in the output tray. go test lines up its results with tabs, so every ok line of a Go build carried two boxes. Each tab now becomes spaces up to the next tab stop, so the columns line up as they do in a terminal. Any other control character a script prints, such as a bell, is now left out rather than drawn as a box.

BuildPilot v1.2.0

Release notes

Typical build time

Every row now shows how long its build usually takes, on a line of its own beneath the status: Typical build time: 3:12. Until now a row showed only the time of its latest run, so pressing Run again threw that away and left nothing to judge the running build against.

The typical time is the median of the operation's last five successful runs. One unusually slow build, such as a first build on a cold cache, does not move it; it also follows a build that has grown quicker or slower. A run that failed or that you stopped does not count, since it says nothing about how long the build takes.

It is shown in every state, including Not run, so it is there straight after BuildPilot starts and after a run you stopped. It is remembered across restarts in run-times.json, a file of its own in the data folder beside buildpilot.json; your settings file is unchanged. Nothing shows for an operation until one of its runs has succeeded.

Removing an operation forgets its run times. If the run times file cannot be read or written, BuildPilot notes it in its log and carries on; the typical times simply start afresh.

BuildPilot v1.1.0

Release notes

Launch installer

Each row now has a Launch installer button, immediately right of Stop. It starts the project's setup program the way Explorer would, so Windows asks for administrator rights where the installer needs them.

BuildPilot finds the installer for you: the working directory's name followed by Setup.exe, looked for in dist-installer and then in dist, matched on letters and digits whatever the case. So fulcrum finds FulcrumSetup.exe and postal-gambit finds PostalGambitSetup.exe. Where a project names its installer differently, set it in the Edit dialog's new Installer field, with its own Browse button; a relative path is taken as inside the working directory. The field shows the installer found when the dialog opens; saving keeps whatever it then holds.

The button is greyed out, with the red ring every disabled control wears, when there is no installer to launch, while the row is running and after a run that you stopped or that failed, until a later run of it succeeds. Its tooltip says which reason applies. A build that writes a new installer is noticed when it ends; one built outside BuildPilot is noticed when you select its row.

To make room for the new field, the Edit dialog's step buttons (Add step, Remove, Up, Down) now sit two by two beside the steps rather than in a column of four, so the dialog fits the window at its usual size.

The output tray shows how a run ended

When a run finished, the tray was meant to end on its green, red or grey closing line. It stopped short instead, leaving that line just out of sight; with a burst of output it could stay at the very top. The tray now keeps itself on the last line whenever new output arrives while it is following, so the closing line is always in view at the end of a run. Scrolling up still stops the following; Jump to latest takes you back to the end.

BuildPilot v1.0.1

Release notes

The selected row stays in sight when the tray opens

In 1.0.0, opening the output tray shortened the list of rows without moving it, so a row you had selected near the foot of the list dropped out of sight just as its output appeared. The list now scrolls just far enough to keep the selected row in view whenever the tray opens or grows; it leaves the list alone when that row is already visible.

BuildPilot v1.0.0

Release notes

The first release of BuildPilot: a Windows flight deck for the build scripts you run every day. It remembers them, starts several side by side, shows each one's state and live output, then stops them with everything they started. It runs the commands you already have and never becomes the build system; every script stays runnable without it.

Your builds, remembered

An operation is one or more steps run in order, a working directory and a name. PowerShell, batch, executable and Python scripts are supported out of the box; Settings maps any other file type to the program that runs it. A step that fails stops the rest. Every step's script is checked before the first one starts, so a missing second script is found before a long first step rather than after it.

Adding a project in one go

Add takes a script or a folder. A folder holding build.ps1 is proposed as a ready-made operation with its name, icon and environment filled in; so is one holding buildexe.py then buildinstaller.py. Choose a folder of projects and each one is listed with a tick box. A project already on the deck is shown but cannot be added twice; a partial match says which file is missing. Nothing is added until you confirm. New rows slot into the deck by name; a row you have moved stays where you put it.

Python environments, used as they are

A Python or PowerShell step runs inside the virtual environment in its working directory, chosen in the dialog when there are several. Any environment BuildPilot inherited from the shell that started it is undone first, so one project's environment never leaks into another's. BuildPilot never creates, installs into or repairs an environment.

Running and watching

Each run is its own process, shown by a glyph and in words with its elapsed time. Run the ticked builds starts every ticked row at once. Two builds are never allowed to run in the same folder, since they would overwrite each other's output. The output tray follows each run live and keeps its latest 100,000 lines. Lines are drawn plainly whichever stream they came on, because many build tools write ordinary progress to stderr; the exit code decides the outcome, shown as a closing line in green, red or grey.

Stopping cleanly

Every run starts inside its own Windows job object, so Stop ends the script and every process it started. A tree still alive five seconds later is reported by process id. Closing BuildPilot with builds running asks first; a crash still takes every run's processes with it.

A window built for the keyboard

Every control is reachable with Tab and the arrow keys and wears a visible focus ring. Every scrolling surface shows a proper scroll bar; the row list says how many rows are out of sight. Light and dark themes follow Windows on the first run. Help holds a Guide to every control, About with the open source credits generated at build time, the licence and Check for Updates.

One network request, no more

BuildPilot asks GitHub whether a newer release is out, shortly after it opens and once a day, carrying nothing about you or your scripts. Nothing else it does touches the network. The toolbar's drink button opens the donation page in your browser; nothing is held back behind a donation.

Installing

BuildPilotSetup.exe installs for your own account only, so Windows never asks for administrator rights. Run it again to update, go back to an earlier version, repair or reinstall. Uninstalling keeps your operations and settings unless you untick that.

What this release commits to

Within this major version, the settings file stays readable by every later release and the install folder stays where it is, so every update installs in place. BuildPilot is a Windows application; there will be no macOS or Linux build.