Currently this system only works for repos with a valid server.sh available in every branch, tag and commit.
Let's decouple that, and rename the concept of "repos" to "servers". A server has a label, an optional repo and an optional script.
The script is the string passed to bash. It gets a PORT environment variable and is expected to start a server listening on the port.
If no script is defined then the fallback is that server.sh in the root of the repo.
But note that repo is optional now! That because you might define a server string that has everything it needs to run a server on its own, independently of a repo. "uvx datasette -p $PORT" for example.
If a server has no repo then only that server label works as a subdomain - there is no --ref mechanism because there is no git repository for those refs to resolve within. Likewise the signing mechanism makes no sense - bare servers (the name for servers without a repo) are always served from their label subdomain eg label.localhost or equivalent.
Single repo mode makes no sense for bare servers.
Bare repos are passed to the CLI like this:
preview-server --bare 'datasette:uvx datasette -p $PORT'
So that's label:script
There is no way to configure a server with both a path AND a custom script using the CLI options - you have to use a config file instead
In the config file servers with scripts (both bare and repos) look like this:
[servers]
frontend = { repo = "/path/to/frontend", script = "uvx run datsette -p $PORT" }
Or for a server with just the script (a bare server):
frontend = { script = "uvx run datsette -p $PORT" }
Rename other parts of the system that use the term "path" to use the term "repo" instead, like in the Python code and JSON
Currently this system only works for repos with a valid server.sh available in every branch, tag and commit.
Let's decouple that, and rename the concept of "repos" to "servers". A server has a label, an optional repo and an optional script.
The script is the string passed to bash. It gets a PORT environment variable and is expected to start a server listening on the port.
If no script is defined then the fallback is that server.sh in the root of the repo.
But note that repo is optional now! That because you might define a server string that has everything it needs to run a server on its own, independently of a repo. "uvx datasette -p $PORT" for example.
If a server has no repo then only that server label works as a subdomain - there is no
--refmechanism because there is no git repository for those refs to resolve within. Likewise the signing mechanism makes no sense - bare servers (the name for servers without a repo) are always served from their label subdomain eglabel.localhostor equivalent.Single repo mode makes no sense for bare servers.
Bare repos are passed to the CLI like this:
So that's label:script
There is no way to configure a server with both a path AND a custom script using the CLI options - you have to use a config file instead
In the config file servers with scripts (both bare and repos) look like this:
Or for a server with just the script (a bare server):
Rename other parts of the system that use the term "path" to use the term "repo" instead, like in the Python code and JSON