141 lines
5.8 KiB
Markdown
141 lines
5.8 KiB
Markdown
# ForgeFlow 0.3.0 release notes
|
|
|
|
Release date: 2026-07-24
|
|
Release type: self-service test release
|
|
|
|
## Goal
|
|
|
|
Version 0.3.0 closes the gap between a functional developer preview and a build
|
|
that can be configured and tested by its owner without sharing credentials with
|
|
a developer. The release concentrates on setup guidance, deterministic
|
|
preflight checks, safe diagnostics and server-side allowlisting.
|
|
|
|
## Setup and readiness
|
|
|
|
- Replaced the lightweight onboarding with a five-step setup wizard.
|
|
- Added a computer readiness preflight for Git, Git identity, writable app data,
|
|
writable diagnostics and OS credential encryption.
|
|
- Added a Gitea validation stage before setup completion.
|
|
- Added visible repository discovery results.
|
|
- Added safe setup diagnostics before Gitea is connected.
|
|
- Added a comprehensive start page and end-to-end setup guide.
|
|
- Added a JSON-capable command-line doctor for local environment validation.
|
|
|
|
## Deployment preflight
|
|
|
|
A deployment now receives a visible preflight before confirmation and a second
|
|
mandatory backend validation immediately before dispatch. Checks include:
|
|
|
|
- linked local Git repository;
|
|
- allowed deployment branch;
|
|
- clean working tree;
|
|
- configured upstream;
|
|
- local/remote ahead and behind state;
|
|
- exact full SHA on the remote branch;
|
|
- local deploy and rollback workflow files;
|
|
- remote workflow visibility through Gitea;
|
|
- Gitea Actions API availability;
|
|
- deployment status endpoint;
|
|
- application health endpoint.
|
|
|
|
Optional environment checks can warn without hiding required failures.
|
|
Deployment cannot bypass the mandatory checks through the renderer.
|
|
|
|
## Diagnostic logging
|
|
|
|
- Added ordered structured JSONL logging in the Electron app-data directory.
|
|
- Added daily files, size rotation and retention pruning.
|
|
- Added configurable logging level, retention and file-size policy.
|
|
- Added process, renderer, Git, repository, Gitea, IPC, preflight and deployment
|
|
diagnostics.
|
|
- Added per-launch session IDs and per-operation deployment request IDs.
|
|
- Added a no-throw logging design so diagnostic storage does not crash the app.
|
|
- Added local clear and open-folder controls.
|
|
|
|
## Secret and privacy protection
|
|
|
|
- Added recursive sensitive-key detection, including camelCase variants.
|
|
- Added bearer/basic/token/password/API-key/client-secret redaction.
|
|
- Added runtime-secret replacement.
|
|
- Added URL credential, token query parameter and private-key redaction.
|
|
- Added common hosting-token pattern redaction.
|
|
- Added user-home and source-root path aliases.
|
|
- Added strict privacy mode with deterministic identifier hashing.
|
|
- Stopped automatically ingesting or persisting raw runner logs; full output stays in Gitea.
|
|
- Added fail-closed bundle auditing before the ZIP is written.
|
|
- Added SHA-256 output for every generated support bundle.
|
|
|
|
No Gitea token, SSH key or server password is needed by the developer to use
|
|
these diagnostics.
|
|
|
|
## Support bundle contents
|
|
|
|
A support bundle can contain:
|
|
|
|
- manifest and safety audit;
|
|
- system and application version information;
|
|
- sanitized public configuration;
|
|
- sanitized repository state;
|
|
- sanitized operation history;
|
|
- latest preflight report;
|
|
- safe diagnostic status;
|
|
- redacted JSONL logs.
|
|
|
|
It intentionally excludes protected token blobs, authorization headers,
|
|
private keys, source files, Git diffs, environment dumps and raw runner output.
|
|
|
|
## Server deployment hardening
|
|
|
|
- Moved target definitions to a root-owned `/etc/forgeflow/targets.conf` file.
|
|
- Added exact repository/environment allowlisting.
|
|
- Made the server status URL mandatory and require matching SHA plus request ID before success.
|
|
- Added configuration ownership and permission checks.
|
|
- Added absolute and restricted path validation.
|
|
- Added exact remote-SHA and branch ancestry validation.
|
|
- Added per-target `flock` locking.
|
|
- Added Docker Compose result and health verification.
|
|
- Added current, previous, requested SHA, request ID and exit code to server
|
|
status output.
|
|
- Added a restrictive sudoers template for the runner.
|
|
- Added explicit deploy and rollback workflow request-ID inputs.
|
|
- Added backend repository re-resolution so renderer-supplied paths and identities
|
|
cannot select an arbitrary local folder or Gitea repository.
|
|
- Captured pre-dispatch Actions run IDs so polling cannot attach to an older run
|
|
with the same commit SHA.
|
|
- Required repository, environment, live SHA, requested SHA, request ID, zero
|
|
server exit code and explicit health success before marking a release complete.
|
|
- Restricted rollback to the exact previous SHA currently reported by the server
|
|
status endpoint.
|
|
|
|
## User interface
|
|
|
|
- Added a dedicated Diagnostics workspace.
|
|
- Added system and deployment preflight presentation.
|
|
- Added diagnostic policy controls.
|
|
- Added Standard and Strict support-bundle export.
|
|
- Added support-bundle checksum and reveal action.
|
|
- Added readiness explanations to onboarding.
|
|
- Replaced duplicate sidebar navigation with a compact safe-diagnostics state.
|
|
|
|
## Validation
|
|
|
|
- 39 required project files validated.
|
|
- 35 JavaScript files passed syntax checks.
|
|
- 36 of 36 automated tests passed.
|
|
- Two real temporary Git remotes remain part of the integration suite.
|
|
- New tests cover redaction, diagnostic rotation/export, support ZIP generation,
|
|
fail-closed safety auditing, preflight and Gitea workflow-file checks.
|
|
|
|
## Known boundaries
|
|
|
|
- The release is not code-signed.
|
|
- A platform-native installer is not guaranteed by the source ZIP alone.
|
|
- The private Gitea, runner and server environment still requires the documented
|
|
local acceptance test.
|
|
- Application-specific compose commands and health endpoints remain target
|
|
configuration, because they cannot be inferred safely.
|
|
- No redactor can mathematically identify an arbitrary unknown secret printed by
|
|
custom third-party code; raw runner logs therefore remain only in the trusted
|
|
Gitea Actions interface, and exported bundles should still be inspected before
|
|
sharing.
|