turnout-cli 0.11.0 → 0.12.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -2
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -74,7 +74,7 @@ And see what has been going on:
|
|
|
74
74
|
|
|
75
75
|
```console
|
|
76
76
|
$ turnout status
|
|
77
|
-
turnout 0.
|
|
77
|
+
turnout 0.12.0
|
|
78
78
|
Data directory: ~/.local/share/lacodda/turnout
|
|
79
79
|
Apps: 2 (api, web)
|
|
80
80
|
Servers: 2 (prod-eu, staging)
|
|
@@ -96,6 +96,7 @@ Recent:
|
|
|
96
96
|
- **A dev gateway.** Apps always talk to `localhost`; turnout forwards to the selected stand over HTTP or HTTPS (self-signed certificates allowed per server), rewrites redirects, proxies WebSockets, and keeps a cookie jar per app+stand pair so switching does not log you out.
|
|
97
97
|
- **Servers, logins and paths kept apart.** A machine, the credential that logs into it and the directory files land in are three named entities. Define a deploy account once and point every stand at it; declare a web root once and reuse it across servers.
|
|
98
98
|
- **Named deploy targets.** The four of them under one name: `turnout deploy web-prod-eu` from any directory, no flags to re-type. A first deploy that has no target yet offers to save the one it just used.
|
|
99
|
+
- **Key access set up, not just used.** `turnout key setup prod` generates an ed25519 key, authorizes it on the server, proves it signs in and only then switches the credential over - so a server-side misconfiguration never costs you the password that still works. Windows servers included: an administrator account keeps its keys in a different file that sshd reads instead, and turnout writes to the right one.
|
|
99
100
|
- **Secrets in the OS keyring** - Windows Credential Manager, macOS Keychain, Linux Secret Service. A secret belongs to a credential, so one `pass set` covers every stand that credential reaches. Copy it to the clipboard with one command; nothing lands in a config file, and `status` only ever reports *that* a credential exists.
|
|
100
101
|
- **Commands from any directory.** `dev`, `build`, `test`, `lint` and any custom command run in the right project folder. Commands are taken from your actual `package.json` scripts, so a project whose dev script is `serve` still answers to `turnout dev`.
|
|
101
102
|
- **Deploy over SSH/SFTP** - build, upload, restart, with remote backup and restore when a release goes wrong. Artifacts travel as a single archive instead of thousands of round trips, falling back to file-by-file when the server cannot unpack one. Linux and Windows servers alike: turnout detects which shell answers SSH and phrases every remote command in it.
|
|
@@ -158,7 +159,6 @@ Full command reference and concepts: **[lacodda.github.io/turnout](https://lacod
|
|
|
158
159
|
|
|
159
160
|
Everything above works today. What is next:
|
|
160
161
|
|
|
161
|
-
- [ ] **Key-based access, set up rather than only used** - generate a key, install it on the server and verify it in one command, including the Windows administrator case
|
|
162
162
|
- [ ] **Background runs** - `dev --detach`, `ps`, `logs`, `stop`, OS notifications
|
|
163
163
|
- [ ] **Observability** - gateway request log, `doctor`, `report` for handing context to an assistant
|
|
164
164
|
- [ ] **Deploy consists** - atomic deploy and rollback across a group of apps
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "turnout-cli",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.12.0",
|
|
4
4
|
"turnout": {
|
|
5
|
-
"binary": "v0.
|
|
5
|
+
"binary": "v0.12.0"
|
|
6
6
|
},
|
|
7
7
|
"description": "A developer's switchyard: point local apps at any backend stand, keep servers and secrets at hand, build and deploy from any directory",
|
|
8
8
|
"license": "MIT",
|