Repository navigation
Optimize release and Pages workflow overhead - #369
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
build_onlyinputs for Release and Pages. Defaults remain false; validation uses isolated concurrency and skips publication/deployment. Release sources still come from the exact verified existing tag.Coverage of every remaining workflow
release.ymldeploy.ymlversion-bump.ymlauto-release.sh, version scripts and their synthetic integration tests. Its 9-12 second preparation job, full-history checkout, serialization, source/version ordering and atomic pushes are deliberately unchanged.Independent branch from main, not stacked on #368. No changes to
tests.yml, either lockfile, settings, secrets, strict ready-only policies, production versions or tags.Measured performance and limits
Baseline: three comparable recent main runs, including Pages 39831367373, 39681819473, 39632333151, and their automatic-release counterparts.
The redundant Pages installation alone previously took 5-9 seconds; it is gone, but this single cold-cache run does not establish an overall Pages latency improvement. Release timings are one nonpublishing validation versus historical samples, not a controlled repeated benchmark. Publication/deployment steps were skipped and runner queueing differs, so total workflow wall times are not compared as equivalent workloads. Warm-cache speedup and billed-cost savings remain unmeasured; the public-repository billing API reports zero billable milliseconds.
Local three-sample archive measurements on real payloads support the compression choices:
Validation
v2.4.8tag identity, release timestamps and every asset ID/digest were unchanged before/after.--publish neverand no signing/publication credentials. Verified the ad-hoc signature, packaged architecture/backend metadata, the actual packaged SQLite binary with an in-memory Electron query, and payload checksums.actionlintincluding shellcheck passed on all three workflows. Real old/new staging scripts produced byte-identical synthetic outputs; each missing artifact and missing manifest payload still failed.Release build-only uses application/build-script sources from the existing tag, not this workflow branch. The changed locked server-install script was validated locally; hosted tag builds do not claim to validate that branch-only script. Automatic version preparation was exercised only with isolated synthetic repositories, never a production bump.
Existing warnings and constraints
ubuntu-latestmigration to Ubuntu 26. This is a runner-image notice, not a failing check.