The build queue

One button takes a project from a cold checkout to a running server or a finished program. The Build Queue beside it lists every open project, one row each.

The button

Build sits on the top bar and on the Terminals view strip. It is the same control in both places and reads the same queue. Pressing Build opens the queue and builds the active project, unless that project is already building or running. The chevron beside it opens or closes the queue without building anything. While any project is building, the hammer on the button turns into a spinner.

The first build

A project with no build script is worked out before it runs. The row reads Analyzing project while an agent reads the project and writes a script for it, and it names the tool the agent is using as it goes. The script covers the whole journey. It checks tools, starts supporting services such as a database, installs packages, compiles, runs tests and frees the ports it needs. Then it launches the server, or runs the program to the end.

If one folder holds several independent projects, the analysis picks the main one and builds only that. An analysis that goes quiet for 5 minutes, or runs past 15, is stopped.

Nothing writes a build script in the background. Only a build you start and Regenerate Script do. The script lives in the data folder, never inside your project. When a build fails, the end of its output is kept, and the next Regenerate Script takes it into account. What earlier failures taught about this machine is fed into every new script too.

The queue

The queue follows the project switcher. A project joins when you open it and leaves when you close it, and closing a project stops its build. Drag a row by its grip to change the order. With nothing open the list reads no projects open.

The head shows Build Queue, the number of projects and Build All. Build All walks the queue in order and skips projects that are already up. It waits for each project to be up or finished before it starts the next one. A project still building after 15 minutes is left running and Build All moves on. A build that fails stops Build All at that project.

A row shows, from left to right, the grip, a status mark, the project name, whether it is a Server or a Run, one log line, its ports, a play or stop control, and a more control that opens the row menu. Right-clicking the row opens the same menu. The status mark spins while the project is being analyzed, built or stopped, and turns into a check when a Run program finishes. Escape closes an open menu first, then the queue.

The log line

Only the newest fact about the build gets a line, and it replaces the one before it rather than stacking.

Copy Log in the row menu copies the output behind that line, up to its last 400 lines.

Ports

A server row shows its port as a chip reading localhost and the port. Click the text to copy the address, and the chip says Copied. The arrow opens the address in your browser. The dot on the chip shows what is listening there, this build, something else, or nothing.

A project with several ports shows one control with the number of ports and a dot for each. It opens a list with a line per port. Each line copies and opens its address the same way, and has a stop that frees the port.

When two projects in the queue declare the same port, their rows carry a warning mark. The row menu then offers Change Port with that port number. It opens a new terminal in the project and asks its agent to move the project to the lowest free port above the old one that no other build script uses. The build keeps the new port once that run finishes.

A program that reads input

While a Run build is going, the row carries a Send input field. Type and press Enter to send a line to the running program.

The row menu

Combined builds

With Build completed tasks together on in Settings > Projects, every build of a git project runs from its own build checkout, never from the project folder itself. Each build starts from the project folder as it stands, including changes you have not committed yet, so an edit made outside Warshall is in the next build or restart. The completed work of every open terminal that is included in builds is combined on top of that, and the result is what runs. Nothing is fetched, so code you have not pulled never appears in your build.

A folder that is not a git repository is built where it is. Once you make it one and commit, the build moves into a checkout of its own.

Each terminal has an Include in builds switch in the WorkMap popup on its head. A task whose terminal is still working is built up to its last completed task, and the row says so.

When a task collides with your folder or with another task, the fallback model resolves the conflict inside the build checkout and nowhere else. If the first attempt does not settle it, it tries once more. Only when both fail does the row say Unable to resolve conflicts, and the build output names the files. Check your project folder for changes that are not staged, or switch a terminal out of builds. When two tasks truly contradict each other, the row menu lists them under Conflicting tasks, keep one. Pick one, and the others stay out of combined builds until you choose Include Every Task.

Before something is stopped

An action that would take a port away from a terminal that is still working asks first. The prompt names the terminal and what it is running, for example Terminal 1 is running localhost:3000, or says how many terminals are still working. It says what the action will do and offers Build anyway, Stop anyway, Free anyway or Restart anyway. When no working terminal uses those ports, the action runs without asking.