@ours.network/install 1.2.0-nightly.2 → 1.2.1-nightly.10

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.
Files changed (39) hide show
  1. package/README.md +151 -131
  2. package/assets/Dockerfile +6 -3
  3. package/assets/docker-compose.yaml +21 -1
  4. package/assets/release-lock.json +7161 -0
  5. package/assets/release.json +57 -0
  6. package/assets/scripts/build/build-common.mjs +1 -1
  7. package/assets/scripts/build/build-sdk.mjs +6 -1
  8. package/assets/scripts/build/record-build.mjs +2 -0
  9. package/assets/scripts/maintenance/build-context.mjs +1 -1
  10. package/assets/scripts/maintenance/daemon-owner.mjs +15 -0
  11. package/assets/scripts/maintenance/docker-layout-conversion.mjs +3 -1
  12. package/assets/scripts/maintenance/release-graph.mjs +111 -0
  13. package/assets/scripts/maintenance/state-operation.mjs +4 -2
  14. package/assets/scripts/runtime/client-setup.mjs +3 -3
  15. package/assets/scripts/runtime/entrypoint.sh +1 -1
  16. package/assets/scripts/runtime/legacy-import.mjs +103 -0
  17. package/assets/scripts/runtime/runtime-common.mjs +2 -0
  18. package/assets/sources.json +96 -16
  19. package/install.mjs +2 -2
  20. package/install.sh +1 -1
  21. package/lib/build-transition.mjs +13 -7
  22. package/lib/client-cli.mjs +117 -0
  23. package/lib/docker-conversion-runtime.mjs +1 -0
  24. package/lib/docker-runtime-repair.mjs +125 -0
  25. package/lib/effects.mjs +163 -85
  26. package/lib/fleet-settings.mjs +43 -0
  27. package/lib/legacy-migration.mjs +202 -0
  28. package/lib/legacy-state.mjs +205 -0
  29. package/lib/managed-cli.mjs +164 -0
  30. package/lib/orchestrate.mjs +162 -58
  31. package/lib/plan.mjs +13 -7
  32. package/lib/prompt.mjs +113 -119
  33. package/lib/server-onboarding.mjs +114 -0
  34. package/lib/setup-options.mjs +253 -0
  35. package/lib/setup.mjs +154 -0
  36. package/lib/target.mjs +4 -4
  37. package/lib/uninstall.mjs +2 -2
  38. package/lib/usage.mjs +49 -44
  39. package/package.json +5 -4
package/README.md CHANGED
@@ -1,159 +1,135 @@
1
- # @ours.network/install — `ours-install`
1
+ # @ours.network/install — one installer for the whole stack
2
2
 
3
- The all-in-one installer for the ours.network stack. One run installs and
4
- configures the shared daemon, MCP adapter, cowork, Telegram connector, Fleet,
5
- and plugins for every safely detected agent harness.
3
+ Requires Node.js 22+ and npm. Install the selected release channel:
6
4
 
7
5
  ```sh
8
- npm install --global @ours.network/install
6
+ npm install -g @ours.network/install@nightly
9
7
  ours-install
10
8
  ```
11
9
 
12
- ### Stable and nightly channels
13
-
14
- Installing `@ours.network/install@latest` selects the stable channel; installing
15
- `@ours.network/install@nightly` selects the nightly channel. Before changing the
16
- machine, the installer resolves `@ours.network/mcp`,
17
- `@ours.network/claude-code`, and `@ours.network/codex`, verifies that their
18
- selected dist-tags expose one exact lockstep version, and fails closed if they
19
- do not. MCP and the Codex launcher are installed by exact version, and local
20
- Claude Code and Codex marketplace manifests pin the corresponding plugin
21
- packages to that same version.
22
-
23
- `OURS_CHANNEL=latest|nightly` (or the legacy `OURS_INSTALL_CHANNEL`) remains an
24
- explicit override. Without an override, the installed package's own version
25
- selects the channel.
26
-
27
- The normal flow uses one daemon at `~/.ours` on port 3050, shows an eight-stage
28
- progress bar, and asks only for information it cannot safely infer (normally the
29
- Human identity's display name). Existing daemon conflicts and moving a Telegram
30
- connector from another daemon still require explicit confirmation.
31
-
32
- ## What the installer does
33
-
34
- - Installs `@ours.network/cli`, `@ours.network/mcp`,
35
- `@ours.network/tg-connector`, `@ours.network/cowork`, and
36
- `@ours.network/fleet` on one release channel.
37
- - Configures, starts, and enables the single shared daemon with a CLI-managed
38
- user systemd service on Linux or LaunchAgent on macOS.
39
- - Creates the daemon's Human identity (historically called the root identity),
40
- or preserves the existing one on a re-run.
41
- - Installs the ours plugin into safely detected Claude Code, Codex, and Hermes
42
- installations.
43
- - Configures and starts cowork as a durable shim over the shared daemon.
44
- - Configures and starts Telegram as a durable shim over the same daemon.
45
- - Runs Fleet's native initialization through prepared settings or its interactive wizard. Fleet owns and
46
- publishes its v2 configuration, including subscriptions, models, roles,
47
- templates, and permissions. The installer does not start Fleet roles.
48
-
49
- The operator CLI owns daemon configuration, lifecycle, and boot persistence.
50
- The MCP package is only the stdio adapter spawned by agent harnesses; the
51
- installer never asks `ours-mcp` to start a daemon.
52
-
53
- Daemon state is temporarily scoped to its package major version. On a same-major
54
- update, the installer refreshes the packages and runs `ours daemon restart`; the
55
- CLI streams structured startup phases until restore is complete instead of
56
- appearing to hang. A different-major update is detected before package
57
- replacement. The installer explains the incompatibility and, only in an
58
- interactive run, offers to stop the CLI-managed daemon, copy the complete state
59
- directory to a timestamped directory under `~/.ours-backups/`, remove the
60
- managed service and old state, then initialize the new major. The default answer is no, and
61
- `OURS_ASSUME_YES` never authorizes this purge.
62
-
63
- ## What remains stopped
64
-
65
- Only Fleet is intentionally not started. Review and activate it when ready:
10
+ With no arguments, the wizard explains each step and offers keyboard choices.
11
+ Use arrow keys and Enter to choose, and Space to select integrations. Recommended
12
+ settings keep advanced ports and package overrides out of the usual flow. Text
13
+ input is used for your name and explicitly customized paths or ports. Linux x64
14
+ recommends native mode; macOS and Windows recommend Docker. On Windows run the
15
+ installer inside WSL with Docker Desktop integration. This recommendation concerns
16
+ packaging and isolation, not a guarantee that emulated x64 is faster on ARM Macs.
17
+
18
+ The same installer accepts complete CLI presets. It reports missing answers before
19
+ changing the machine and never opens hidden prompts when arguments are supplied.
20
+ Both forms show the same preparation, identity, update and readiness progress.
66
21
 
67
22
  ```sh
68
- # After completing Fleet's wizard and reviewing ~/fleet.yaml:
69
- ours-fleet doctor
70
- ours-fleet config
71
- ours-fleet up
72
- ours-fleet ls
23
+ # Whole stack, with prepared Fleet settings and no interactive prompts:
24
+ ours-install --mode docker --state-dir "$HOME/ours-docker" \
25
+ --identity-name "Your Name" --integrations codex,fleet \
26
+ --fleet-settings "$HOME/fleet-settings.json"
27
+
28
+ # Native server only; native and packages mean the same mode:
29
+ ours-install server --mode native --state-dir "$HOME/ours-native" \
30
+ --identity-name "Your Name"
31
+
32
+ # Clients connected to an existing server:
33
+ ours-install client --config /private/client/profile.json \
34
+ --integrations codex,fleet --fleet-settings /private/fleet-settings.json
35
+
36
+ # Update a retained complete installation and its clients:
37
+ ours-install all update --mode docker --state-dir "$HOME/ours-docker" \
38
+ --identity-name "Your Name" --integrations codex,fleet \
39
+ --fleet-settings "$HOME/fleet-settings.json" --compatible
73
40
  ```
74
41
 
75
- The final installer screen repeats these commands and provides a copy-paste
76
- prompt for Claude Code, Codex, or Hermes. The agent should guide local bot-token
77
- entry without asking the user to paste the secret into chat.
42
+ `server` and `client` are presets of the same flow, not separate interactive
43
+ installers. `--integrations none` explicitly skips client integrations. Use
44
+ `--dry-run` with a complete preset to preview it, and `--help` for all options.
45
+ Fleet's own wizard is available only in interactive setup; CLI Fleet setup requires
46
+ its JSON settings file. Fleet stays stopped until you review and activate it.
78
47
 
79
- ## Preview and automation
48
+ The server installs the daemon/SDK/CLI, Telegram, Cowork and Messenger.
49
+ It starts the daemon, preserves the existing Human identity (or creates it once),
50
+ then starts its applications. Full-stack setup issues a separate local client
51
+ credential and configures the selected Codex, Claude Code and Fleet integrations.
52
+ Existing identity keys and names are retained on update. An update's storage
53
+ compatibility must be reviewed before supplying `--compatible`.
80
54
 
81
- ```sh
82
- ours-install --dry-run
83
- OURS_ASSUME_YES=1 ours-install
84
- ours-install --state-dir /absolute/path --port 3070
85
- ```
55
+ The installer embeds exact component versions and SHA-512 values for its release.
56
+ An existing server's retained release selects matching local clients. Secrets are
57
+ read from protected files, and client setup never copies the daemon API master.
86
58
 
87
- Dry-run walks the real plan without writing files, installing packages, starting
88
- processes, or changing services. `OURS_ASSUME_YES=1` uses the OS username for a
89
- new Human identity and asks no ordinary setup questions, but it never bypasses
90
- selection conflicts, connector moves, or destructive safeguards.
91
-
92
- A non-default daemon must be selected coherently with a config file or matching
93
- port and state directory. Hermes and the generated Fleet role persist that
94
- selection through `OURS_CONFIG`. Claude Code and Codex plugin registrations
95
- cannot store an environment value; for those harnesses the installer prints the
96
- exact `export OURS_CONFIG=...` line that must be added to the shell profile
97
- before starting the harness. There is no per-application daemon.
98
-
99
- `OURS_CONFIG` may also name a prepared private host profile containing the
100
- complete `endpoint`, `expectedInstanceId`, and absolute `credentialPath` tuple.
101
- The profile and credential must already be regular current-user files with
102
- private permissions. In this mode the installer verifies `/selection` before
103
- sending the credential to `/version`, installs only MCP, detected Claude/Codex
104
- plugins, and Fleet client support, and never creates, starts, stops, or services
105
- a host daemon. Telegram, cowork, messenger, daemon voice, and daemon state stay
106
- Compose-owned. If `OURS_CONFIG` is unset, the same profile is discovered at
107
- `~/.ours/config.json`; a legacy config there keeps the existing local behavior.
108
-
109
- ## Uninstall
59
+ ## Runtime and client packages
110
60
 
111
- ```sh
112
- ours-uninstall --state-dir "$HOME/.ours"
113
- ours-uninstall --state-dir "$HOME/.ours" --purge
114
- ```
61
+ Server selections include `@ours.network/daemon`, whose `ours-daemon` binary owns
62
+ runtime startup and service administration. Docker runs `ours-daemon serve`;
63
+ native installations install its systemd/launchd service. Existing retained
64
+ installations can still stop and restore their older CLI-owned runtime.
115
65
 
116
- The uninstaller delegates service and daemon removal to the `ours` CLI. Identity
117
- state is retained by default. Purging requires the existing destructive gates and
118
- targets only the explicit state directory.
66
+ Client selections contain the thin SDK and CLI, plus MCP when a harness needs
67
+ it. They exclude the daemon and its native database/ADAPT dependencies. Fleet
68
+ runs beside the harnesses on the client machine and calls the daemon HTTP API.
69
+ Client commands report an unavailable server and never start one automatically.
119
70
 
120
- When `OURS_CONFIG` selects a host profile, uninstall removes only selected
121
- client attachments. The operator-owned profile and shared credential are kept
122
- even with `--purge`, and no Compose daemon, service, or state is touched.
71
+ The development policy selects published SDK `3.8.1-nightly.9`, CLI
72
+ `2.8.1-nightly.7`, and daemon `3.8.1-nightly.1`, together with exact reviewed
73
+ consumer source commits. The isolated host CLI pair uses these released client
74
+ artifacts. The nightly release manifest selects the complete published consumer
75
+ set and standalone daemon with verified SHA512 integrities. Packaged installers
76
+ use this exact release set; mixed or unselected nested SDK versions remain rejected.
123
77
 
124
- ## Release channel
78
+ ## Migrate an existing global installation
125
79
 
126
- `OURS_CHANNEL=nightly` (or `OURS_INSTALL_CHANNEL`) selects the packages' nightly
127
- dist-tags. Without an override, the installer's own version selects the channel.
128
- The operator CLI intentionally has no nightly dist-tag and remains untagged on
129
- both channels.
80
+ The wizard detects the old `~/.ours/config.json` and offers to keep its identities,
81
+ messages, keys and settings in the new installation. It follows the configured
82
+ state directory, including a custom location. An equivalent unattended preset is:
130
83
 
131
- ## Environment
84
+ ```sh
85
+ ours-install all --mode docker --state-dir "$HOME/ours-docker" \
86
+ --migrate-from "$HOME/.ours/config.json" --compatible --integrations codex
87
+ ```
132
88
 
133
- - `OURS_ASSUME_YES=1`: accept safe defaults without prompting.
134
- - `OURS_INSTALL_DRY_RUN=1`: preview without mutation.
135
- - `OURS_NPM`: npm executable.
136
- - `OURS_CONFIG`: explicit legacy daemon config or prepared private host profile.
137
- - `OURS_STATE_DIR`: explicit daemon state directory.
138
- - `OURS_CHANNEL`: `latest` or `nightly`.
89
+ Run the old daemon before the first migration so the installer can record and
90
+ verify its identities. The new runtime is downloaded/built first. Then the old
91
+ boot service and daemon stop, and the complete daemon state is copied while its
92
+ writer lock is held. Docker migration imports that copy into its named storage
93
+ volume. Existing Human/role names and CIDs must match before applications start;
94
+ migration never creates a replacement Human.
95
+
96
+ The original state/configuration remain unchanged. A private `legacy-backup`
97
+ directory stores the original config/service definition, and
98
+ `legacy-client/profile.json` is a prepared connection profile for the new server.
99
+ Selected integrations are configured by the usual client setup. The global `ours` command is switched to a launcher for the managed installation
100
+ only after verifying ownership of its existing npm entry; foreign or read-only
101
+ commands are refused before migration. Ordinary `ours identity list` is checked
102
+ after cutover. Lifecycle commands manage the new installation, and selection
103
+ overrides cannot accidentally return to the old daemon. The old configuration is
104
+ not reinterpreted as a client profile. Do not start the old state alongside the
105
+ migrated daemon. Reinstalling the global CLI with npm can replace the launcher;
106
+ repeat the same migration command to verify and repair that routing.
107
+
108
+ Repeat the same command after an interruption. Once the destination has started,
109
+ retries repair it in place instead of replacing it with an older source snapshot.
110
+ The source is kept stopped after an activation failure to avoid diverging identity
111
+ sessions. Migration requires local Linux/macOS (or WSL) with `node:sqlite` support,
112
+ a verifiable old CLI/service, and a separate target directory. External PostgreSQL
113
+ history or unsupported external MCP/token-delivery paths are refused before
114
+ shutdown. Unrelated application data outside the daemon tree is not copied.
139
115
 
140
116
  ## Selected network installations (2.0)
141
117
 
142
118
  The installed package carries its compatible `assets/sources.json` policy.
143
- `--sources` remains available as an explicit development override. Feature
144
- revisions in the testing delivery remain unpublished; local build evidence does
145
- not prove remote fetchability or compatibility of a replacement source set.
119
+ `--sources` remains available as an explicit development override. Published releases bind that policy to exact component versions and registry
120
+ SHA-512 values. Acquisition validates the ours dependency graph before activation.
121
+ A development override without a release binding is not a qualified product release.
146
122
 
147
123
  ```sh
148
- ours-install server install --mode docker --state-dir /private/ours-install
149
- ours-install server install --mode packages --state-dir /private/ours-install
124
+ ours-install server install --mode docker --state-dir /private/ours-install --identity-name "Your Name"
125
+ ours-install server install --mode packages --state-dir /private/ours-install --identity-name "Your Name"
150
126
  ours-install server status --state-dir /private/ours-install
151
127
  ours-install server stop --state-dir /private/ours-install
152
128
  ours-install server start --state-dir /private/ours-install
153
129
  ours-install server restart --state-dir /private/ours-install
154
130
  ```
155
131
 
156
- Choose one mode for a private installation root. The private `installation.json`
132
+ Choose one mode and a folder for its programs and data. The private `installation.json`
157
133
  records mode, instance selection, configuration/source paths and service selection;
158
134
  it never records master bytes or an issued-token registry. The selected policy
159
135
  is resolved to an exact, role-filtered `sources.json` before acquisition.
@@ -169,8 +145,19 @@ Linux/WSL or a launchd GUI user domain on macOS. Source builds also require Git,
169
145
  Python 3, a C/C++ toolchain, make, and the selected repositories' own prerequisites.
170
146
  Docker mode requires a working Docker engine and Compose 2.35+; its build image
171
147
  contains the source-build prerequisites. No bind or Docker socket mounts are used.
172
- Server runtime installation selects SDK/CLI, main MCP, Telegram, Cowork and
173
- Messenger. Main MCP is injected into the daemon, not started as a second daemon.
148
+ Docker is recommended for macOS and Windows. Install and start Docker Desktop
149
+ on those hosts; on Linux, install Docker Engine and the Compose plugin. If Docker
150
+ is unavailable, the installer explains how to install/start it or use
151
+ `server install --mode packages --state-dir <new-empty-directory>` instead.
152
+ Native Windows installations require WSL with a working systemd user manager.
153
+ The installer never switches an existing installation's mode automatically.
154
+ Server installation shows each stage before it starts, streams Docker builds and
155
+ native package acquisition, and reports completion only after service readiness.
156
+ If a Docker service fails, the error includes its last 50 log lines (bounded in
157
+ size) and a command to inspect the logs. A failed daemon prevents consumers from
158
+ starting; a failed consumer does not prevent checks of unrelated consumers.
159
+ Server runtime installation selects SDK/CLI, Telegram, Cowork and
160
+ Messenger. MCP runs locally with the Codex and Claude Code plugins and calls the daemon API through the SDK.
174
161
  The daemon starts first; consumers are checked through their owning readiness
175
162
  interfaces. Messenger uses its existing identity prerequisite and never creates an
176
163
  identity. Its failure is reported after attempting unrelated consumers. Package
@@ -219,7 +206,7 @@ client-owned installer settings:
219
206
  ```
220
207
 
221
208
  ```sh
222
- ours-install client install --config /private/client/profile.json
209
+ ours-install client install --config /private/client/profile.json --integrations codex,claude-code
223
210
  ```
224
211
 
225
212
  Optional `sourcesPath` and `fleetSettingsPath` values are absolute or resolved
@@ -227,9 +214,9 @@ relative to the profile file. Select any nonempty subset of integrations; Fleet
227
214
  When Fleet settings are supplied, the installer passes them to Fleet's strict
228
215
  noninteractive `init --settings`; otherwise it opens Fleet's existing wizard.
229
216
  Fleet validates and publishes its own configuration. Client setup verifies the selected
230
- daemon and packaged OURS MCP before registering native integrations. It acquires
217
+ authenticated daemon API before registering native integrations. It acquires
231
218
  only selected integration packages and their actual client dependencies. It does
232
- not install main MCP, administer daemon state or invoke Docker. Exact npm client
219
+ not administer daemon state or invoke Docker. Codex and Claude Code include the local stdio MCP server as a dependency. Exact npm client
233
220
  installation needs no Python; Git source builds use the supplied source recipes
234
221
  and their build prerequisites. Normal native clients need neither Docker nor
235
222
  server maintenance tools.
@@ -256,7 +243,7 @@ Interactive no-argument installation asks for package/Docker server mode, a
256
243
  prepared client profile, or `client`. Client setup offers the saved server when
257
244
  present. On first setup it asks for the server HTTP endpoint, issued-token file,
258
245
  source manifest and integration choices, obtains the instance UUID from
259
- `/selection`, displays it, then checks authenticated daemon and MCP access before
246
+ `/selection`, displays it, then checks authenticated daemon API access before
260
247
  saving anything. No UUID must be entered manually. The 2.0 HTTP flow assumes the
261
248
  approved trusted same-host deployment; selection metadata is not cryptographic
262
249
  server authentication. Fleet collects missing setup answers through its own wizard.
@@ -269,7 +256,7 @@ For a managed server, maintenance runs on the server machine through the install
269
256
  ours-install server backup server snapshot --state-dir /path/to/installation
270
257
  ours-install server restore server snapshot --state-dir /path/to/installation
271
258
  ours-install server rebuild --state-dir /path/to/installation
272
- ours-install server update --state-dir /path/to/installation --compatible
259
+ ours-install server update --mode docker --state-dir /path/to/installation --identity-name "Your Name" --compatible
273
260
  ```
274
261
 
275
262
  Backup and restore support the full server or an individual `daemon`, `telegram`,
@@ -313,3 +300,36 @@ maintenance reads both formats. Format2 is not readable by older maintenance too
313
300
  so this change does not promise executable downgrade support. Restore validates the
314
301
  original archive records unchanged, then writes markers for the active target runtime.
315
302
  Mixed/incomplete context and component record sets are refused before activation.
303
+
304
+ ### Retrying a Docker installation after a source-policy permission failure
305
+
306
+ Setup verifies the selected Docker image before reusing it, including when the image
307
+ already exists. If an older installer left a root-owned, mode-0600
308
+ `/opt/ours/sources.json`, setup repairs only that image file's permissions and
309
+ continues. The selected package bytes, build provenance, image execution settings,
310
+ credentials and stored data are retained. The old materialized Dockerfile's known
311
+ COPY instruction is also corrected for future builds. No manual image or volume
312
+ deletion is required; repeat the original setup with the updated installer.
313
+
314
+ The repair runs isolated verification containers without state mounts or network
315
+ access. Other image verification failures stop setup without replacing the image.
316
+ An interrupted repair can be retried, including after the image tag was replaced.
317
+
318
+ ### Remote clients over HTTPS
319
+
320
+ A client may select an `https://` origin backed by a TLS reverse proxy. Keep the
321
+ daemon listener private and configure the proxy separately with a certificate
322
+ trusted by the client and matching the hostname. Node uses its normal trust
323
+ store; a private CA may be supplied through `NODE_EXTRA_CA_CERTS` before starting
324
+ the client. Certificate verification must remain enabled.
325
+
326
+ The existing issued client credential works over either transport; changing the
327
+ URL scheme does not require a new credential. Keep the server's master on the
328
+ server. Forward `x-ours-api-token` and the `x-ours-*` session headers unchanged,
329
+ and support streamed request/response bodies and long polling. Client requests
330
+ refuse redirects, including HTTPS-to-HTTP redirects: configure the final HTTPS
331
+ origin directly. UUID/capability checks still precede credential-bearing calls.
332
+
333
+ This adds client HTTPS support, not an HTTPS daemon listener, certificate
334
+ provisioning or automatic reverse-proxy configuration. Existing local HTTP and
335
+ SSH-tunnel profiles continue to work.
package/assets/Dockerfile CHANGED
@@ -3,9 +3,11 @@ FROM node:24 AS toolchain
3
3
  RUN apt-get update && apt-get install -y --no-install-recommends build-essential python3 ca-certificates git && rm -rf /var/lib/apt/lists/*
4
4
  FROM toolchain AS build
5
5
  WORKDIR /opt/ours
6
- COPY sources.json /opt/ours/sources.json
6
+ # The host selection is private (0600); this non-secret image policy must be
7
+ # readable by arbitrary runtime UIDs while remaining root-owned and non-writable.
8
+ COPY --chmod=644 sources.json /opt/ours/sources.json
7
9
  COPY scripts/build/*.mjs /build-scripts/
8
- COPY scripts/maintenance/build-context.mjs scripts/maintenance/provenance-compare.mjs /maintenance/
10
+ COPY scripts/maintenance/build-context.mjs scripts/maintenance/provenance-compare.mjs scripts/maintenance/release-graph.mjs /maintenance/
9
11
  RUN --mount=type=secret,id=github_token --mount=type=cache,id=ours-dist-2-npm,target=/root/.npm,sharing=locked node /build-scripts/build.mjs
10
12
  # Testing delivery: npm resolves transitive versions afresh; repeat builds may differ.
11
13
  # build.mjs creates package.json once from the sources.json selections.
@@ -16,11 +18,12 @@ RUN node /build-scripts/record-build.mjs
16
18
  # must be able to read it. Protected state/host copies retain private ownership.
17
19
  RUN chmod 755 /opt/ours /opt/ours/docker /opt/ours/docker/vendor && chmod 644 package.json package-lock.json dependency-tree.json build-context.json docker/vendor/*.tgz
18
20
  LABEL network.ours.build-context="1"
19
- COPY scripts/maintenance/build-context.mjs scripts/maintenance/provenance-compare.mjs /opt/ours/maintenance/
21
+ COPY scripts/maintenance/build-context.mjs scripts/maintenance/provenance-compare.mjs scripts/maintenance/release-graph.mjs /opt/ours/maintenance/
20
22
  COPY scripts/runtime/runtime-common.mjs /opt/ours/docker/runtime-common.mjs
21
23
  COPY scripts/runtime/check-client.mjs /opt/ours/docker/check-client.mjs
22
24
  COPY scripts/runtime/check-start.mjs /opt/ours/docker/check-start.mjs
23
25
  COPY scripts/runtime/client-setup.mjs /opt/ours/docker/client-setup.mjs
26
+ COPY scripts/runtime/legacy-import.mjs /opt/ours/docker/legacy-import.mjs
24
27
  COPY scripts/runtime/entrypoint.sh /opt/ours/docker/entrypoint.sh
25
28
  COPY scripts/runtime/healthcheck.mjs /opt/ours/docker/healthcheck.mjs
26
29
  COPY scripts/runtime/start-telegram.sh scripts/runtime/health-telegram.sh scripts/runtime/start-cowork.sh scripts/runtime/health-cowork.sh scripts/runtime/start-messenger.sh scripts/runtime/health-messenger.mjs /opt/ours/docker/
@@ -177,6 +177,26 @@ services:
177
177
  start_period: 30s
178
178
  retries: 12
179
179
 
180
+ legacy-import:
181
+ profiles: [maintenance]
182
+ build:
183
+ <<: *source-build
184
+ target: maintenance
185
+ platform: linux/amd64
186
+ image: "${OURS_MAINTENANCE_IMAGE:-ours-compose-2-maintenance:local}"
187
+ user: "0:0"
188
+ network_mode: none
189
+ read_only: true
190
+ cap_drop: [ALL]
191
+ cap_add: [CHOWN, DAC_OVERRIDE]
192
+ security_opt: [no-new-privileges:true]
193
+ entrypoint: [node, /opt/ours/docker/legacy-import.mjs]
194
+ environment:
195
+ OURS_UID: "${OURS_UID:-1000}"
196
+ OURS_GID: "${OURS_GID:-1000}"
197
+ volumes:
198
+ - {type: volume, source: server-storage, target: /storage, volume: {nocopy: true}}
199
+
180
200
  state-operation:
181
201
  profiles: [maintenance]
182
202
  build:
@@ -195,7 +215,7 @@ services:
195
215
  OURS_STATE_ROOT: /storage
196
216
  OURS_LIVE_ROOT: "${OURS_LIVE_ROOT:-/storage/state}"
197
217
  OURS_BUILD_ROOT: /opt/ours
198
- OURS_CLI_PATH: /opt/ours/node_modules/.bin/ours
218
+ OURS_DAEMON_BIN_DIR: /opt/ours/node_modules/.bin
199
219
  OURS_DAEMON_CONFIG: /var/lib/ours/config.json
200
220
  OURS_COWORK_CLI_PATH: /opt/ours/node_modules/.bin/ours-cowork
201
221
  OURS_COWORK_CONFIG: /var/lib/ours-cowork/config.json