Release ForgeFlow 0.6.0
This commit is contained in:
NuklearRabbit
@@ -0,0 +1,73 @@
|
||||
# ForgeFlow 0.6.0 release audit
|
||||
|
||||
## Scope
|
||||
|
||||
This audit covers the source release intended for publication to `Jens/ForgeFlow` and subsequent installation through ForgeFlow's built-in source updater.
|
||||
|
||||
Reviewed areas:
|
||||
|
||||
- local Git discovery, status, staging, commit, push, fetch and fast-forward;
|
||||
- large Windows path selections and deleted/renamed files;
|
||||
- stale Git lock diagnosis, conservative repair and automatic retry;
|
||||
- divergence recovery with a safety branch;
|
||||
- Gitea repository and Actions integration;
|
||||
- SSH host identity, Unraid-to-Gitea preflight and exact-SHA deployment;
|
||||
- Docker Compose identity normalization while preserving visible container names;
|
||||
- DockerMan WebUI, icon and shell labels, XML fallback and cache refresh;
|
||||
- interrupted/stale deployment reconciliation;
|
||||
- renderer viewport behavior and guided troubleshooting;
|
||||
- diagnostics redaction and support bundles;
|
||||
- release publication and built-in source-update lifecycle.
|
||||
|
||||
## Regression coverage
|
||||
|
||||
The automated suite contains 99 passing tests, including real temporary Git repositories and bare remotes. High-risk regressions covered directly include:
|
||||
|
||||
- staged and unstaged deletions;
|
||||
- renamed files;
|
||||
- a local commit followed by a failed push;
|
||||
- 850 long selected paths transported through NUL-delimited stdin;
|
||||
- stale `HEAD.lock` removal while excluding Git object/LFS storage;
|
||||
- backup-before-reset repair of a diverged branch;
|
||||
- exact remote-SHA checks;
|
||||
- background SSH deployment completion without a stuck operation;
|
||||
- startup/manual reconciliation of live Unraid state;
|
||||
- lowercase-safe Compose project/service/image identities with visible `Portfolio` casing;
|
||||
- DockerMan labels, built-in icon upload, XML fallback and cache invalidation;
|
||||
- source-updater STARTED handshake, result acknowledgement, direct Electron restart and rollback state.
|
||||
|
||||
## Product behavior added for the reported incidents
|
||||
|
||||
- Git mutations are serialized per repository.
|
||||
- A lock failure triggers a safe diagnosis and one automatic repair/retry when no active Git process is detected.
|
||||
- Git Tools provides personalized scan, lock repair, origin repair, fast-forward, push and safety-branch divergence recovery actions.
|
||||
- Successful SSH deployments become terminal before the secondary server refresh, preventing a live container from leaving ForgeFlow in deployment mode.
|
||||
- ForgeFlow refreshes configured server truth after startup and through the combined refresh action.
|
||||
- A healthy live SHA equal to local/Gitea is not offered for deployment again.
|
||||
- Running containers missing DockerMan metadata can be repaired individually or in one batch from Deployments.
|
||||
- Built-in/uploaded icons are placed in persistent DockerMan storage, referenced through a `file:///` label, written into a user template and copied into known icon caches.
|
||||
- WebUI uses the Unraid label placeholders based on the configured host port and path.
|
||||
- Update publication creates and publishes `package-lock.json`; the updater uses `npm ci` when it is present.
|
||||
- Update success is persisted before restart, and restart invokes Electron directly rather than relying on a detached npm process.
|
||||
|
||||
## Static and packaging checks
|
||||
|
||||
- every JavaScript/CJS/MJS source file passes `node --check`;
|
||||
- required source, branding, documentation, updater and deployment files are present;
|
||||
- direct dependency versions are pinned;
|
||||
- renderer privileged actions remain behind the preload/IPC boundary;
|
||||
- the PowerShell update helper starts with `param(`, has no UTF-8 BOM and contains lifecycle state before shutdown/restart;
|
||||
- release archives exclude `.git`, `node_modules`, `dist`, update downloads and generated ZIPs;
|
||||
- the generated source manifest records SHA-256 and size for every distributed source file.
|
||||
|
||||
## Remaining live acceptance step
|
||||
|
||||
The automated environment cannot execute Windows PowerShell 5.1 or connect to the user's private Gitea/Unraid services. The final live acceptance is therefore deliberately the requested workflow:
|
||||
|
||||
1. publish the release from an extracted Downloads folder;
|
||||
2. leave the installed older source at `C:\Projects\ForgeFlow` untouched;
|
||||
3. open that older ForgeFlow;
|
||||
4. use **Settings → ForgeFlow updates → Check now → Download update → Apply & restart**;
|
||||
5. confirm the restarted application reports version 0.6.0 and displays the persisted success result.
|
||||
|
||||
A failed handoff must keep the old app open. A failed validation must restore the previous source. A successful installation remains installed even when only automatic restart fails.
|
||||
@@ -0,0 +1,20 @@
|
||||
# ForgeFlow 0.5.3
|
||||
|
||||
## Confirmed source-update handoff
|
||||
|
||||
- ForgeFlow writes a launch request and waits for an external PowerShell **STARTED marker** before closing.
|
||||
- A helper launch failure or timeout leaves ForgeFlow open and surfaces the real error.
|
||||
- The updater records structured lifecycle state alongside the detailed update log.
|
||||
- Successful installation remains valid even when automatic restart is unavailable.
|
||||
- The next manual start shows a **visible update result** for success, failure, or rollback.
|
||||
- The PowerShell helper uses the absolute Windows PowerShell executable where available.
|
||||
- Success and rollback both attempt an **automatic restart**, with the result persisted for diagnosis.
|
||||
|
||||
## Included 0.5.x reliability improvements
|
||||
|
||||
- viewport-safe, scrollable deployment and settings dialogs;
|
||||
- sticky modal action bars;
|
||||
- large Git selections through NUL-delimited pathspec input;
|
||||
- serialized repository mutations;
|
||||
- SSH password-form persistence correction;
|
||||
- origin normalization and stale-index-lock repair.
|
||||
@@ -0,0 +1,10 @@
|
||||
# ForgeFlow 0.5.4
|
||||
|
||||
This release repairs the first real SSH / Unraid deployment path.
|
||||
|
||||
- Preflight now verifies **Unraid → Gitea access** with the exact configured clone URL before deployment can start.
|
||||
- SSH deployments run as a **background deployment** operation; the interface returns immediately and polls the real operation state.
|
||||
- Failed SSH or Docker operations are written back as terminal failed operations instead of leaving the UI indefinitely active.
|
||||
- Compose service and container casing are preserved, so the requested name **Portfolio** remains Portfolio.
|
||||
- Generated Compose no longer forces service names to lowercase.
|
||||
- Deployment status refreshes automatically until success or failure.
|
||||
@@ -0,0 +1,61 @@
|
||||
# ForgeFlow 0.6.0
|
||||
|
||||
ForgeFlow 0.6.0 is a product-level reliability release for Git recovery, SSH / Unraid deployment truth, DockerMan integration, source updating and high-contrast ITWorx branding.
|
||||
|
||||
## Git operations that recover themselves
|
||||
|
||||
- Every mutating Git action is serialized per repository.
|
||||
- A Git lock error triggers a conservative stale-lock scan, a short grace period for very recent locks, safe removal and automatic retry when ForgeFlow can prove that no matching process is active.
|
||||
- The scanner resolves the actual Git directory and covers `HEAD.lock`, `index.lock`, ref locks and worktree locks while skipping Git object/LFS storage.
|
||||
- The Git tools page now provides repository-specific troubleshooting instead of generic terminal advice.
|
||||
- Available automated actions are selected from the actual branch state: fetch, fast-forward, push, origin repair and divergence recovery.
|
||||
- Divergence recovery creates a `forgeflow/backup-<branch>-<timestamp>` safety branch before resetting the current branch to upstream.
|
||||
|
||||
## Deployment truth instead of stuck spinners
|
||||
|
||||
- SSH / Unraid operations are reconciled with the live Git SHA, container state and health.
|
||||
- Startup deployment reconciliation converts an interrupted but successful deployment to `success` and refreshes repository cards immediately.
|
||||
- Stale operations are marked failed instead of remaining indefinitely in `running`.
|
||||
- Deployment cards provide **Reconcile**, **Open Web UI** and **Repair DockerMan integration** actions.
|
||||
- Background completion broadcasts update the renderer and trigger repository refresh.
|
||||
|
||||
|
||||
- A successful remote Compose run is marked terminal before the secondary Unraid inspection, so a slow refresh can no longer leave the UI stuck in deployment mode.
|
||||
- Startup and manual refresh reconcile every configured environment and suppress a new Deploy action when the exact healthy SHA is already live.
|
||||
- The Deployments page can repair all running containers that are missing DockerMan WebUI/icon metadata in one controlled batch.
|
||||
|
||||
## DockerMan integration
|
||||
|
||||
- ForgeFlow applies `net.unraid.docker.managed=dockerman`, `net.unraid.docker.webui`, `net.unraid.docker.icon` and `net.unraid.docker.shell` through a controlled Compose override.
|
||||
- WebUI labels use Unraid's `[IP]` and `[PORT:<host-port>]` placeholders.
|
||||
- Internal Compose project, service and image identities are lowercase-safe while the visible container name can remain `Portfolio`.
|
||||
- The built-in high-contrast ITWorx mark is the default DockerMan icon for new or migrated SSH profiles.
|
||||
- A user can instead select a local PNG, use an HTTP(S) PNG URL or disable the icon.
|
||||
- Built-in/uploaded PNGs are copied persistently to DockerMan's image storage under `/boot/config/plugins/dockerMan/images`.
|
||||
- ForgeFlow writes a persistent `templates-user/my-<container>.xml` fallback so WebUI and icon metadata remain available when label caching is unreliable.
|
||||
- Known DockerMan icon caches and the volatile metadata cache are invalidated after container recreation so changes can be re-read.
|
||||
|
||||
## SSH and server-side safety
|
||||
|
||||
- Unraid-to-Gitea access remains part of preflight before any deployment starts.
|
||||
- SFTP directory creation now distinguishes existing directories from permission and path errors instead of treating every generic SFTP failure as success.
|
||||
- Repository Compose files receive the same metadata and exact-SHA controls as generated Compose files.
|
||||
- Tracked server-side modifications continue to block deployment and rollback.
|
||||
|
||||
## Source updater and publication
|
||||
|
||||
- The PowerShell update helper starts directly with `param(`, without a UTF-8 BOM or stray leading character.
|
||||
- ForgeFlow waits for a structured `started` marker before closing the running application.
|
||||
- Update application performs backup, exact archive checksum validation, source replacement, lockfile-based `npm ci` when available and the complete quality gate.
|
||||
- Success, restart failure and rollback status are persisted and shown on the next launch.
|
||||
- Automatic restart launches the installed Electron executable directly, avoiding the unreliable detached `npm start` handoff.
|
||||
- The publishing script runs the quality gate, mirrors a clean source tree and verifies that Gitea reports the exact pushed release commit.
|
||||
|
||||
## Branding
|
||||
|
||||
- The title bar, setup flow, desktop icon and installer artwork use the newly supplied higher-contrast ITWorx.tech logo.
|
||||
- The cloud/check mark was recropped to remove wordmark fragments and remain legible at small icon sizes.
|
||||
|
||||
## Verification
|
||||
|
||||
The release includes real Git integration coverage for large selections, staged deletions, failed pushes, `HEAD.lock`, object-store exclusion and backup-before-reset divergence recovery. It also covers DockerMan labels and XML fallback, built-in icon upload, cache invalidation, operation reconciliation, viewport-safe dialogs and updater lifecycle behavior.
|
||||
@@ -1,112 +1,95 @@
|
||||
# SSH / Unraid deployment
|
||||
|
||||
ForgeFlow 0.4 can deploy an exact Gitea commit directly to an Unraid server over SSH.
|
||||
ForgeFlow deploys an exact Gitea commit directly to an Unraid server over pinned SSH.
|
||||
|
||||
## Security model
|
||||
|
||||
- Enter credentials only in the local ForgeFlow desktop window.
|
||||
- Prefer an Ed25519 private key over a password.
|
||||
- ForgeFlow stores passwords and private-key passphrases through Electron safe storage.
|
||||
- The first successful test records the SSH host-key fingerprint.
|
||||
- Later connections fail closed when that fingerprint changes.
|
||||
- Diagnostics redact the Gitea token, SSH password and private-key passphrase.
|
||||
- ForgeFlow never sends arbitrary commands entered through the renderer. Deployment commands are assembled from validated profile fields.
|
||||
- Credentials are entered only in the local ForgeFlow desktop application.
|
||||
- Ed25519 private keys are preferred.
|
||||
- Passwords and key passphrases use Electron safe storage.
|
||||
- The first trusted connection records the SSH host-key fingerprint; later changes fail closed.
|
||||
- Unraid-to-Gitea repository access is tested during every deployment preflight.
|
||||
- The renderer cannot submit arbitrary shell commands. Remote scripts are assembled from validated profile fields and transported as base64-encoded Bash input.
|
||||
- Tracked server-side modifications block deployment and rollback.
|
||||
|
||||
## Configure the server
|
||||
## Profile identity
|
||||
|
||||
Open **Settings → SSH / Unraid servers → Add server**.
|
||||
|
||||
Typical Unraid values:
|
||||
ForgeFlow separates names that users see from names Docker requires:
|
||||
|
||||
```text
|
||||
Name: Unraid
|
||||
Host: 192.168.1.10
|
||||
Port: 22
|
||||
Username: root
|
||||
Base path: /mnt/user/appdata
|
||||
Auth: Private key
|
||||
Visible project/container: Portfolio
|
||||
Server folder: Portfolio
|
||||
Internal Compose project: portfolio
|
||||
Internal Compose service: portfolio
|
||||
Internal image: forgeflow/portfolio:production
|
||||
```
|
||||
|
||||
Save the server, then choose **Test & trust**. ForgeFlow verifies SSH, Git and Docker Compose and records the host-key fingerprint.
|
||||
The internal Compose service must match the repository's service key and remain lowercase. The visible container can preserve branding and casing.
|
||||
|
||||
## DockerMan WebUI, icon and shell
|
||||
|
||||
ForgeFlow writes `.forgeflow/compose.metadata.yml` and combines it with the repository or generated Compose file. The override supplies:
|
||||
|
||||
```text
|
||||
net.unraid.docker.managed=dockerman
|
||||
net.unraid.docker.webui=http://[IP]:[PORT:<host-port>]/
|
||||
net.unraid.docker.icon=<PNG URL or persistent Unraid path>
|
||||
net.unraid.docker.shell=sh
|
||||
```
|
||||
|
||||
Icon modes:
|
||||
|
||||
- **Built-in high-contrast ITWorx mark** — default;
|
||||
- **Upload local PNG** — copied to `/boot/config/plugins/dockerMan/images/<container>-icon.png`;
|
||||
- **Use icon URL** — HTTP(S) PNG;
|
||||
- **No custom icon**.
|
||||
|
||||
After metadata changes ForgeFlow recreates the container, writes `/boot/config/plugins/dockerMan/templates-user/my-<container>.xml`, removes known icon caches and invalidates DockerMan's volatile `docker.json` metadata cache. The Unraid Docker page may still need one browser refresh.
|
||||
|
||||
The deployment card reports whether WebUI and icon labels were confirmed through `docker inspect`. **Repair DockerMan integration** recreates an existing healthy container with labels, a persistent DockerMan template, icon cache refresh and WebUI metadata without creating a Git commit. **Open Web UI** uses the profile URL directly from the desktop.
|
||||
|
||||
## Existing application folder
|
||||
|
||||
Create a deployment profile and choose **SSH / Unraid**.
|
||||
|
||||
For an existing folder:
|
||||
|
||||
```text
|
||||
Server folder: lumaops
|
||||
Remote path: /mnt/user/appdata/lumaops
|
||||
Server folder: Portfolio
|
||||
Remote path: /mnt/user/appdata/Portfolio
|
||||
Compose file: docker-compose.yml
|
||||
```
|
||||
|
||||
ForgeFlow inspects the folder before deployment. An existing deployment is adopted only when the project root is a Git working tree. Tracked server-side changes block deployment. Untracked runtime paths such as `.env`, `appdata`, `data`, `logs`, `config` and `compose.override.yml` remain untouched by `git reset --hard`.
|
||||
The project root must be a Git working tree. Untracked runtime paths such as `.env`, `appdata`, `data`, `logs`, `config` and `compose.override.yml` remain untouched by `git reset --hard`. Nested Git repositories are warnings and never deleted automatically.
|
||||
|
||||
Keep the root `.git` directory. It is used to verify the exact commit, update the working tree and roll back to the previous SHA.
|
||||
|
||||
Nested Git repositories are reported as warnings and are never removed automatically.
|
||||
|
||||
When a Dockerfile is present, preflight also inspects `.dockerignore`. It reports
|
||||
whether `.git` is excluded and warns when existing preserved runtime folders or
|
||||
nested repositories would still be sent as Docker build context. Fix those
|
||||
rules in the repository and commit them rather than changing only the live
|
||||
server copy.
|
||||
Preflight inspects `.dockerignore` when a Dockerfile exists. It warns when `.git`, preserved runtime data or nested repositories would be sent into the build context.
|
||||
|
||||
## New application folder
|
||||
|
||||
For a new project, ForgeFlow creates:
|
||||
The server clones the configured URL on the selected branch. The Unraid host therefore needs a non-interactive Gitea SSH identity. Preflight runs `git ls-remote --exit-code` from Unraid before deployment.
|
||||
|
||||
```text
|
||||
/mnt/user/appdata/<repository-name>
|
||||
```
|
||||
|
||||
The Unraid server clones the configured Git URL on the selected branch. The server therefore needs access to that repository, normally through an SSH deploy key or an existing trusted Gitea SSH identity.
|
||||
|
||||
Two Compose modes are available:
|
||||
|
||||
1. **Use repository Compose file** — recommended for real applications. Keep ports, volumes, devices, networks and Unraid labels version-controlled.
|
||||
2. **Generate basic ForgeFlow Compose** — suitable for a simple Dockerfile-based application. ForgeFlow asks for host port, container port, service/container name, Web UI URL and icon URL and writes `.forgeflow/compose.forgeflow.yml`.
|
||||
|
||||
Generated Compose deliberately stays minimal. Projects requiring USB devices, GPU access, custom networks, secrets or multiple services should provide their own Compose file.
|
||||
Use repository Compose for real applications. Generated Compose is intended only for a simple single-service Dockerfile application with basic port mapping.
|
||||
|
||||
## Deployment sequence
|
||||
|
||||
1. Verify that the local repository is clean, on the allowed branch and fully synchronized with Gitea.
|
||||
2. Verify that the exact requested SHA exists on `origin/<branch>`.
|
||||
3. Verify the repository Compose file or Dockerfile locally.
|
||||
4. Connect through pinned SSH.
|
||||
5. Inspect the target folder.
|
||||
6. Refuse tracked server-only modifications.
|
||||
7. Clone when the folder does not exist.
|
||||
8. Fetch the configured branch without allowing interactive credential prompts.
|
||||
9. Verify again on the server that the requested full SHA belongs to `origin/<branch>`.
|
||||
10. Save the current SHA as the rollback target.
|
||||
11. Reset the working tree to the exact requested SHA.
|
||||
12. Validate the selected Compose file.
|
||||
13. Run `docker compose up -d --build --remove-orphans`.
|
||||
14. Store non-secret state under `.forgeflow/` and run the configured healthcheck.
|
||||
1. Verify clean local tree, allowed branch, upstream and ahead/behind state.
|
||||
2. Verify the exact SHA exists on the allowed remote branch.
|
||||
3. Verify Unraid can read the Gitea repository.
|
||||
4. Inspect the server folder and refuse tracked server changes.
|
||||
5. Clone when the folder is absent.
|
||||
6. Fetch the branch and verify the exact SHA is an ancestor of `origin/<branch>`.
|
||||
7. Save the previous SHA and reset to the requested SHA.
|
||||
8. Write generated Compose when selected.
|
||||
9. Write the DockerMan metadata override and persistent template fallback.
|
||||
10. Validate the merged Compose model.
|
||||
11. Run `docker compose up -d --build --remove-orphans --force-recreate`.
|
||||
12. Clear relevant icon caches.
|
||||
13. Inspect the visible container and write `.forgeflow/status.json`.
|
||||
14. Run the configured desktop healthcheck.
|
||||
15. Persist the live SHA, previous SHA, health, container and DockerMan state.
|
||||
|
||||
## Folder names
|
||||
## Interrupted operation recovery
|
||||
|
||||
The default folder is the repository name. Existing deployments can keep another folder name by entering it explicitly in the profile. ForgeFlow does not rename populated application folders automatically because Docker paths, scripts and external integrations may depend on them.
|
||||
|
||||
A later controlled migration can align names after a successful backup and downtime window.
|
||||
At startup and through **Reconcile**, ForgeFlow reads the live SHA, container running state, Docker health, labels and persistent template state. When a previously running operation already reached its exact requested SHA and the container is healthy, the operation becomes `success`. Operations that remain unresolved for more than 45 minutes become `failed` rather than staying indefinitely in deployment mode.
|
||||
|
||||
## Rollback
|
||||
|
||||
After a successful deployment, the previous SHA is stored in:
|
||||
|
||||
```text
|
||||
.forgeflow/previous-sha
|
||||
```
|
||||
|
||||
Rollback is accepted only for the exact SHA currently recorded as the previous
|
||||
deployment. ForgeFlow rechecks that SHA against the configured Gitea branch,
|
||||
refuses tracked server-side changes, resets the same working tree, runs Docker
|
||||
Compose again and repeats the healthcheck. The version that was live before the
|
||||
rollback becomes the new rollback target.
|
||||
|
||||
## Before the first real deployment
|
||||
|
||||
Back up the application folder and its persistent data. Run **Preflight** and resolve every failed check. Warnings, such as a nested Git repository, should be reviewed but do not automatically delete or modify anything.
|
||||
Rollback is accepted only for the exact SHA currently recorded as `previousSha`. ForgeFlow re-verifies that commit against Gitea, refuses tracked server changes, resets the same working tree, reapplies Compose and DockerMan metadata, reruns health checks and rotates the former live SHA into the new rollback target.
|
||||
|
||||
+35
-46
@@ -1,60 +1,49 @@
|
||||
# Updating ForgeFlow on Windows
|
||||
|
||||
ForgeFlow stores its local token, server credentials, repository mappings,
|
||||
preferences, deployment profiles, diagnostics and operation history outside the
|
||||
source directory.
|
||||
ForgeFlow stores credentials, repository mappings, preferences, deployment profiles, diagnostics and operation history outside the source directory.
|
||||
|
||||
## Manual update to v0.4.0
|
||||
## Built-in source update
|
||||
|
||||
1. Close ForgeFlow.
|
||||
2. Extract the v0.4.0 update package.
|
||||
3. Copy the contents of its `ForgeFlow` folder over the existing source folder.
|
||||
4. Do not create `ForgeFlow\ForgeFlow`.
|
||||
5. Open PowerShell in the existing folder.
|
||||
6. Run:
|
||||
|
||||
```powershell
|
||||
Set-ExecutionPolicy -Scope Process Bypass
|
||||
.\update-windows.ps1
|
||||
```
|
||||
|
||||
The script installs the new `ssh2` dependency, runs the environment doctor,
|
||||
verifies the source and executes all tests before starting ForgeFlow.
|
||||
|
||||
## Built-in updates after v0.4.0
|
||||
|
||||
Open **Settings → ForgeFlow updates**.
|
||||
|
||||
The default source is:
|
||||
|
||||
```text
|
||||
Gitea instance: the instance already configured in ForgeFlow
|
||||
Repository: Jens/ForgeFlow
|
||||
Branch: main
|
||||
```
|
||||
|
||||
The repository must contain a newer semantic version in `package.json`.
|
||||
|
||||
Choose:
|
||||
Open **Settings → ForgeFlow updates** and choose:
|
||||
|
||||
1. **Check now**
|
||||
2. **Download update**
|
||||
3. **Apply & restart**
|
||||
|
||||
The source updater downloads the exact branch commit, records a SHA-256 checksum,
|
||||
backs up the installed source, applies the archive, runs `npm install` and
|
||||
`npm run check`, and restarts ForgeFlow. When validation fails it restores the
|
||||
previous source and starts that version again.
|
||||
The default update source is the configured Gitea instance, repository `Jens/ForgeFlow`, branch `main`.
|
||||
|
||||
The update log is written beneath ForgeFlow's local user-data `updates` folder
|
||||
and does not contain the Gitea token.
|
||||
The updater pins the download to the exact remote commit, checks the archive SHA-256, starts an external PowerShell helper and waits for a structured `started` marker. ForgeFlow closes only after that marker exists. The helper then:
|
||||
|
||||
The updater deliberately checks the semantic version stored in the remote
|
||||
`package.json`. Merely pushing a new commit without increasing that version does
|
||||
not present an update. Publish the complete validated ForgeFlow source to the
|
||||
configured repository and bump the version for every release.
|
||||
1. waits for the old process to exit;
|
||||
2. backs up the current source;
|
||||
3. extracts and validates the requested semantic version;
|
||||
4. mirrors the incoming source;
|
||||
5. runs `npm ci --no-audit --no-fund` when the published release contains `package-lock.json`, otherwise a pinned direct-dependency `npm install`;
|
||||
6. runs `npm run check`;
|
||||
7. writes the successful installation result before restart;
|
||||
8. launches the installed Electron executable directly;
|
||||
9. persists `success`, `failed` or `rolled-back` state for the next launch.
|
||||
|
||||
A failed validation restores the previous source. A successful installation is not rolled back merely because automatic restart fails; start ForgeFlow manually and the persisted result is shown.
|
||||
|
||||
## Publishing v0.5.1 from a Downloads folder
|
||||
Update logs and status files are stored beneath ForgeFlow's local user-data `updates` folder and exclude the Gitea token.
|
||||
|
||||
Extract the complete release and run `Publish-ForgeFlow-Release.ps1`. The script validates the source, clones `Jens/ForgeFlow` into a temporary directory, mirrors the verified source, commits it and pushes `main`. Keep the currently running older ForgeFlow source folder untouched; use its **Settings → Updates** screen to test the exact-commit download, validation, rollback and restart path.
|
||||
## Publishing a release from Downloads
|
||||
|
||||
Extract the complete source ZIP so this file exists:
|
||||
|
||||
```text
|
||||
C:\Users\Jens\Downloads\ForgeFlow-<version>\ForgeFlow\package.json
|
||||
```
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
cd C:\Users\Jens\Downloads\ForgeFlow-<version>\ForgeFlow
|
||||
Set-ExecutionPolicy -Scope Process Bypass
|
||||
.\Publish-ForgeFlow-Release.ps1
|
||||
```
|
||||
|
||||
The script installs dependencies, runs the complete quality gate, clones `git@gitea.itworx.tech:Jens/ForgeFlow.git` into a temporary folder, mirrors the validated source without `.git`, `node_modules`, `dist` or release archives, commits it and pushes `main`. It then compares local `HEAD` with `git ls-remote` and fails if Gitea does not report the exact release commit.
|
||||
|
||||
Keep the currently installed older ForgeFlow source folder untouched until the built-in updater test is complete.
|
||||
|
||||
Reference in New Issue
Block a user