Skip to content

ci: run lint before build steps - #313

Open
simongdavies wants to merge 1 commit into
simongdavies-npm-linux-arm64-packagingfrom
simongdavies-lint-before-build-in-ci
Open

simongdavies wants to merge 1 commit into
simongdavies-npm-linux-arm64-packagingfrom
simongdavies-lint-before-build-in-ci

Conversation

@simongdavies

Copy link
Copy Markdown
Member

Moves the lint step in .github/workflows/dep_build.yml so it runs before the two build steps.

Step order in the build job goes from:

install nodejs -> Sign node for Hypervisor.framework (macOS) -> fmt -> Build -> Build js-host-api -> lint -> test -> examples...

to:

install nodejs -> Sign node for Hypervisor.framework (macOS) -> fmt -> lint -> Build -> Build js-host-api -> test -> examples...

Why

  • just lint runs cargo hyperlight clippy -p hyperlight-js-runtime, cargo clippy --all-targets, and lint-js (eslint, which does its own npm install). None of those need build artifacts from the preceding steps, so nothing was gained by running lint later.
  • clippy executes build.rs, which builds and links the guest, so lint-first also catches guest toolchain and link failures. This is not theoretical: during Add macOS (hvf) and aarch64 support #308 a macOS llvm-ar failure surfaced only in the Build step, many minutes in, when lint-first would have caught it.
  • clippy and cargo build have separate fingerprints, so reordering them does not duplicate compilation work.
  • Net effect: cheap, fast-failing checks run before expensive ones — the conventional ordering — shortening the feedback loop on a matrix of 10+ jobs, several on scarce self-hosted runners.

Scope

Ordering only. The diff is 3 insertions / 3 deletions; parsing the workflow before and after yields an identical set of steps in a different order. fail-fast and the macOS-only steps from #308 (Set up LLVM guest toolchain, Sign node for Hypervisor.framework) are untouched.

Part of stack #311. Base is simongdavies-npm-linux-arm64-packaging (#310).

`just lint` runs cargo hyperlight clippy, cargo clippy --all-targets and
lint-js, none of which need artifacts from the preceding build steps, so
nothing was gained by running it after them.

clippy executes build.rs, which builds and links the guest, so lint-first
also catches guest toolchain and link failures. This is not theoretical:
during PR #308 a macOS llvm-ar failure surfaced only in the Build step,
many minutes in, when lint-first would have caught it.

clippy and cargo build have separate fingerprints, so the reorder does not
duplicate compilation work.

Net effect: cheap, fast-failing checks run before expensive ones, which
shortens the feedback loop on a matrix of 10+ jobs, several of which run
on scarce self-hosted runners.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Simon Davies <simongdavies@users.noreply.github.com>
@simongdavies simongdavies added the kind/enhancement New feature or improvement label Sep 16, 2026
@simongdavies
simongdavies added this pull request to stack #311 September 16, 2026 20:57
@simongdavies simongdavies added the ready-for-review PR is ready for (re-)review label Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/enhancement New feature or improvement ready-for-review PR is ready for (re-)review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants