@studiometa/forge-cli 0.5.4 → 0.5.5

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 CHANGED
@@ -218,7 +218,7 @@ A worker or a scheduled job matches the file when its command, directory, proces
218
218
  - Without the `workers` key, no worker is read or deleted. With `"workers": []`, all the workers of the site are deleted. The same applies to `schedule`.
219
219
  - The site, its aliases, its database and its `.env` keys are never deleted.
220
220
 
221
- `loadBalancer` sends the traffic of the load balancer to the server of the file. The site of the load balancer is the one named `domain` or one of the `aliases`. When no site matches, `--check` and `apply` exit `3` before any change. When two sites match, they exit `3` too. The Forge API cannot create a site on a load balancer: create it in Forge (New site on the load balancer), with its certificate. To move a site to another server, change `server`: `apply` creates the site there, then moves the node, with no DNS change. It does not delete the site on the old server.
221
+ `loadBalancer` sends the traffic of the load balancer to the server of the file. The site of the load balancer is the one named `domain` or one of the `aliases`. When no site matches, `--check` and `apply` exit `3` before any change. When two sites match, they exit `3` too. The Forge API cannot create a site on a load balancer: create it in Forge (New site on the load balancer), with its certificate. The DNS points to the load balancer, so a change of node needs no DNS change. To move a site to another server, do not only change `server`: `apply` would send the traffic to the new site at once, before its first deployment and without its data. Declare the new server in a second site file without `loadBalancer`, deploy and test it, then move `loadBalancer` to that file. Only one site file declares `loadBalancer` for a site: with the key in two files, each `apply` replaces the node of the other.
222
222
 
223
223
  With `--check`, `apply` prints the plan and changes nothing. It exits `0` when Forge matches the file, `1` when it differs, and another code on an error (`3` for an invalid file). Every deletion shows its ID and full command. The plan gives `.env` key names only, never values, and shows a generated password as `<generated>`. With `--format json`, it prints `{ "inSync": false, "changes": [...], "warnings": [...] }`.
224
224
 
package/dist/cli.js CHANGED
@@ -5566,6 +5566,9 @@ async function applySiteFile(file, serverId, ctx, options = {}) {
5566
5566
  server_id: serverId,
5567
5567
  type: file.type,
5568
5568
  name: file.domain,
5569
+ domain_mode: "custom",
5570
+ www_redirect_type: "none",
5571
+ allow_wildcard_subdomains: false,
5569
5572
  ...settings.php_version ? { php_version: settings.php_version } : {},
5570
5573
  ...settings.web_directory ? { web_directory: settings.web_directory } : {},
5571
5574
  ...settings.source_control_provider ? { source_control_provider: settings.source_control_provider } : {},
@@ -6796,7 +6799,7 @@ function isVersionRequest({ command, options }) {
6796
6799
  }
6797
6800
  //#endregion
6798
6801
  //#region src/cli.ts
6799
- var VERSION = "0.5.4";
6802
+ var VERSION = "0.5.5";
6800
6803
  function showHelp() {
6801
6804
  console.log(`
6802
6805
  ${colors.bold("forge")} v${VERSION}