Baton Manual

Chapter 3

Workspaces

A workspace is a directory of YAML files. On desktop you point Baton at a folder and that folder is the workspace; in a browser there is no folder to point at, so the build keeps one in the browser’s own storage and git sync is how it leaves.

3.1Opening and creating

The workspace menu. — 1: The workspaces you have opened; 2: On the desktop, pick a folder; 3: What the worker runs, and when
  1. The workspaces you have opened
  2. On the desktop, pick a folder
  3. What the worker runs, and when
Figure 6: The workspace menu.

The workspace name at the top left opens the list. 1 is what you have open. 2 adds one — on the desktop it asks for a folder, because a workspace is a folder. 3 opens the schedules the worker runs. On desktop, New workspace… asks for a folder — a workspace is a folder, so there is nothing else to name. The bundled demo-apis workspace is always there to try things against; it is the one this manual uses throughout.

3.2Settings that belong to the workspace

baton.yaml carries the settings every request in that workspace inherits: request timeout, whether redirects are followed, whether TLS certificates are validated, an extra CA bundle or client certificate, and a proxy. They are edited in Settings, and because they live in the workspace they travel with it through git — a colleague who clones the repository gets the same behaviour.

A workspace can be published as a link that opens it: an https:// link to the site, which renders the repository’s coordinates and offers the app, and a baton:// scheme link for platforms with no universal links. Both carry coordinates only. A token, a password or anything resembling a credential in such a link is refused outright rather than quietly stripped.