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

This branch has not been deployed

No deployments
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