updater fixed
This commit is contained in:
@@ -21,3 +21,10 @@ The server verifies the checksum and archive paths, rejects symlink payloads, pr
|
||||
Adopted workloads retain their existing Compose project, Compose files and service set. ForgeFlow no longer overrides their image or container name in the metadata overlay. Existing DockerMan templates are left untouched; generated templates are managed only for explicitly generated Compose profiles. `--force-recreate` and `--remove-orphans` are opt-in rather than defaults.
|
||||
|
||||
A deployment lock records the live shell process, and an old lock is removed only when it is sufficiently old and its owner no longer runs. Deployment output truncation now fails explicitly instead of allowing ForgeFlow to interpret an incomplete inventory or command result.
|
||||
## Release publication correction
|
||||
|
||||
- The standard release publisher now publishes the validated source and matching Windows binary assets as one workflow.
|
||||
- Added `Publish-Missing-Binary-Release.ps1` to repair a source-only Gitea release without reinstalling ForgeFlow manually.
|
||||
- Binary publication now derives the repository owner, repository name and branch from ForgeFlow settings instead of hardcoding them.
|
||||
- Missing-release errors now explain that packaged installations require both Windows executables and their SHA-256 sidecars.
|
||||
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
# ForgeFlow 0.9.1
|
||||
|
||||
## Gitea binary updater repair
|
||||
|
||||
- Downloads the actual release attachment through `browser_download_url` instead of treating the Gitea attachment metadata response as an executable.
|
||||
- Keeps the Gitea token on the configured Gitea origin and follows HTTPS object-storage redirects without leaking credentials.
|
||||
- Adds regression coverage for attachment metadata lookup, direct browser download URLs and cross-origin redirect safety.
|
||||
- Improves diagnostics when an older updater receives JSON attachment metadata.
|
||||
|
||||
Because ForgeFlow 0.8.9 and 0.9.0 contain the broken attachment endpoint, upgrading to 0.9.1 requires one manual installer run. in-app updates work normally again after 0.9.1 is installed.
|
||||
+17
-7
@@ -30,19 +30,29 @@ Update logs and status files are stored beneath ForgeFlow's local user-data `upd
|
||||
|
||||
## Packaged Windows updates
|
||||
|
||||
ForgeFlow 0.8.2 and newer use authenticated Gitea release assets when running from the installer or portable executable. The updater selects the installer or portable artifact that matches the current installation mode, requires its `.sha256` sidecar, validates the Windows executable header and SHA-256 digest, then verifies the digest again immediately before applying it. An external PowerShell helper waits for ForgeFlow to exit, installs or replaces the executable and restarts it.
|
||||
ForgeFlow 0.9.1 and newer use authenticated Gitea release assets when running from the installer or portable executable. The updater selects the installer or portable artifact that matches the current installation mode, requires its `.sha256` sidecar, validates the Windows executable header and SHA-256 digest, then verifies the digest again immediately before applying it. An external PowerShell helper waits for ForgeFlow to exit, installs or replaces the executable and restarts it.
|
||||
|
||||
Publish a verified binary release after pushing its source commit:
|
||||
`Publish-ForgeFlow-Release.ps1` now treats source and binaries as one release transaction. By default it pushes the validated source, builds the exact published commit and uploads all four required assets:
|
||||
|
||||
- `ForgeFlow-Setup-<version>-win-x64.exe`
|
||||
- `ForgeFlow-Setup-<version>-win-x64.exe.sha256`
|
||||
- `ForgeFlow-Portable-<version>-win-x64.exe`
|
||||
- `ForgeFlow-Portable-<version>-win-x64.exe.sha256`
|
||||
|
||||
Use `-SkipBinaryRelease` only when intentionally publishing source without enabling packaged auto-update.
|
||||
|
||||
When the source was already pushed without a binary release, run the recovery publisher from Windows:
|
||||
|
||||
```powershell
|
||||
npm run dist:win
|
||||
$env:FORGEFLOW_USER_DATA = "$env:APPDATA\forgeflow"
|
||||
npm run release:binary
|
||||
Set-ExecutionPolicy -Scope Process Bypass
|
||||
.\Publish-Missing-Binary-Release.ps1 -ExpectedVersion 0.9.1
|
||||
```
|
||||
|
||||
The recovery script clones the current Gitea branch into a temporary directory, verifies the exact branch commit, runs the complete quality gate, builds both Windows artifacts and creates or repairs the matching Gitea release. It uses the encrypted Gitea token already stored by ForgeFlow.
|
||||
|
||||
Every platform build finishes by removing ForgeFlow artifacts for older versions from `dist`. The unpacked application directory and builder diagnostics are kept.
|
||||
|
||||
The publisher refuses to upload when local `HEAD` differs from `origin/main`. Users on 0.8.1 or older need one manual 0.8.2 installation because those versions deliberately disabled packaged updates.
|
||||
The binary publisher refuses to upload when local `HEAD` differs from the configured Gitea branch. ForgeFlow 0.8.9 and 0.9.0 queried Gitea attachment metadata as though it were the executable. Those versions require one manual 0.9.1 installer run. From 0.9.1 onward, the updater follows the release asset browser download URL and in-app updates work normally.
|
||||
|
||||
## Publishing a release from Downloads
|
||||
|
||||
@@ -60,6 +70,6 @@ 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.
|
||||
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`, builds the exact published checkout and uploads the installer, portable executable and both checksums to the matching Gitea release. Publication fails when either the source commit or any required binary asset cannot be verified.
|
||||
|
||||
Keep the currently installed older ForgeFlow source folder untouched until the built-in updater test is complete.
|
||||
|
||||
Reference in New Issue
Block a user