The workflow must keep reviewing every PR and every pushed commit automatically, including fork PRs, so the hardening focuses on pinning the code that actually runs in the secrets-bearing job. The wrapper action commit still delegates to a mutable Docker tag, so the workflow now calls the PR-Agent container by immutable digest directly.
Constraint: Maintainer preference is automatic PR-Agent coverage for each PR and synchronize event.
Constraint: Issue #222 requires removing mutable third-party execution refs from the secrets-bearing path.
Rejected: Pin only the action repository commit | the wrapper Dockerfile still resolves pragent/pr-agent:github_action at runtime.
Rejected: Require trusted comment triggers for fork PRs | too inconvenient because new commits would not be reviewed automatically.
Confidence: medium
Scope-risk: moderate
Directive: If fork PR automation remains required, keep the runtime container digest-pinned and do not checkout PR head code in this workflow.
Tested: Parsed .github/workflows/pr-agent.yml with PyYAML and asserted docker:// sha256 form; git diff --check; grep confirmed no action ref or github_action tag remains in the workflow.
Not-tested: Live GitHub Actions execution or Docker Hub digest pull from this host.
Related: https://github.com/appergb/openless/issues/222
Intel and Apple Silicon macOS jobs produced the same updater bundle filename,
which let one matrix job overwrite the other release asset and could point
both architecture manifests to a single binary. Rename macOS updater bundles
per architecture before release upload and prefer arch-specific artifact lookup
when generating updater manifests.
Constraint: Keep existing updater manifest format and release action usage
Rejected: Split macOS uploads into separate release jobs | larger workflow churn
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Any new macOS updater lane must keep unique asset names to preserve manifest correctness
Tested: release-tauri.yml YAML parse; diff audit for rename+manifest path alignment
Not-tested: End-to-end tagged GitHub Actions release run
The release workflow only produced Apple Silicon macOS packages, so Intel
users had no official GitHub Release artifact. Extend the matrix with an
x86_64 macOS lane and align artifact naming and updater-manifest paths
with per-arch outputs.
Constraint: Keep existing release pipeline shape and signing flow unchanged
Rejected: Split Intel build into separate workflow file | higher maintenance and duplicated logic
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep macOS conditions architecture-agnostic so new mac runners are not skipped accidentally
Tested: YAML syntax parse via python yaml.safe_load; workflow diff reviewed for mac gating/artifact paths
Not-tested: Full GitHub Actions matrix run on tag push
* Remove fragile space from active app path
The Tauri app lived under a path containing a literal space, which made CI paths and local commands easy to quote incorrectly. Rename the active tree to openless-all and update repository references so scripts, docs, and release workflows use the same space-free path.
Constraint: Preserve the existing app layout and move only the containing directory name.
Rejected: Add compatibility symlinks | would keep two app paths and leave quoting hazards in place.
Confidence: high
Scope-risk: moderate
Tested: npm run build
Tested: cargo clean && cargo check
Tested: git diff --check
Tested: grep -R for old openless -all and openless%20-all references
* Keep Windows build docs aligned with space-free path
The app directory was renamed to openless-all, but the GNU/MinGW route still described the new name as if it contained a space. Update the wording so the rationale matches the current path and keeps the helper-script guidance focused on consistent GNU setup.
Constraint: Documentation-only code review follow-up.
Confidence: high
Scope-risk: narrow
Tested: git diff --check
The workflow logic already runs Windows and Linux builds in separate conditional steps. This note makes the intended split explicit so future edits do not accidentally reintroduce a second Linux build path.
Constraint: Keep changes minimal and scoped to existing release workflow
Rejected: Restructure build steps again in this pass | unnecessary churn for a comment-only review follow-up
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep Linux bundle generation in the dedicated Linux step only
Tested: Parsed .github/workflows/release-tauri.yml with yaml.safe_load
Not-tested: Full GitHub Actions run after this comment-only change
The repository already had a single cross-platform release workflow for macOS and Windows.
This change extends the same workflow matrix with Ubuntu so Linux packaging runs in the
same release lane and publishes deb/rpm/AppImage artifacts consistently.
Constraint: Keep existing macOS and Windows release behavior unchanged
Constraint: User requested minimum-scope change in existing workflow rather than new pipeline
Rejected: Add a separate Linux workflow file | would duplicate release logic and increase drift risk
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep Linux package paths aligned with Tauri bundle output dirs when upgrading Tauri
Tested: YAML parse check for .github/workflows/release-tauri.yml
Not-tested: End-to-end GitHub Actions run in remote CI after push
baiqing