Lucas Manuel Rodriguez
c482646efe
**Related issue:** N/A — fixes the `check-doc-gen` job failing on `main` The "Check automated documentation is up-to-date" workflow has been failing on every push to `main` (and every PR that triggers it) since ~18:30 UTC 2026-07-27. The failing step, "Verify osquery table JSON schema is up-to-date," runs `cd website && npm install && sails run generate-merged-schema` and fails if `git diff` is non-empty afterward. The diff it fails on is `website/package-lock.json` itself: `sails-hook-grunt`'s published tarball ships a `node_modules` folder with packages that aren't part of its dependency graph (dev leftovers like `mocha@3.0.2` and `growl@1.9.2`). Newer npm on the CI runners records those on-disk packages in the lockfile as `"extraneous": true` entries, so any committed lockfile that omits them (e.g. after #49852 regenerated it) no longer matches what `npm install` produces — and any committed lockfile that *includes* them gets flagged by `dependency-review` for the critical `growl@1.9.2` advisory (GHSA-qh2h-chj9-jffq), even though growl is never actually installable from the dependency graph. This PR fixes the root cause instead of chasing npm's output: - **`check-doc-gen` now uses `npm ci` instead of `npm install`** — `npm ci` never rewrites `package-lock.json`, so the step's `git diff` check only catches what it's meant to catch (schema drift), and future runner npm upgrades can't reintroduce lockfile churn. - **`website/package-lock.json` regenerated with `npm install --package-lock-only`** — drops the 107 `extraneous` entries (including `growl@1.9.2`) that were committed to pacify the old `npm install`-based check. No dependency versions change; `npm ci --dry-run` validates the lockfile is in sync. # Checklist for submitter If some of the following don't apply, delete the relevant line. ## Testing - [x] QA'd all new/changed functionality manually — verified locally that `npm ci --dry-run` accepts the updated lockfile and that `growl`/`extraneous` entries are gone. Since this PR now modifies the workflow file itself, the `pull_request` path filter triggers `check-doc-gen` on this PR, verifying the `npm ci` path end-to-end in CI. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Improved automated schema validation by using deterministic dependency installation to reduce unnecessary lockfile churn. * Refreshed the generated-schema failure message with the correct regeneration steps to follow when updates are detected. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Github Actions
Fleet uses Github Actions for continuous integration (CI). This document describes best practices and at patterns for writing and maintaining Fleet's Github Actions workflows.
Bash
By default, Github Actions sets the shell to bash -e for linux and MacOS runners. To help write
safer bash scripts in run jobs and avoid common issues, override the default by adding the following
to the workflow file
defaults:
run:
# fail-fast using bash -eo pipefail. See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference
shell: bash
By specifying the default shell to bash, some extra flags are set. The option pipefail changes
the behaviour when using the pipe | operator such that if any command in a pipeline fails, that
commands return code will be used a the return code for the whole pipeline. Consider the following
example in test-go.yaml
- name: Run Go Tests
run: |
# omitted ...
make test-go 2>&1 | tee /tmp/gotest.log
If the pipefail option was not set, this job would always succeed because tee would always
return success. This is not the intended behavior. Instead, we want the job to fail if make test-go fails.
Concurrency
Github Action runners are limited. If a lot of workflows are queued, they will wait in pending until a runner becomes available. This has caused issue in the past where workflows take an excessively long time to start. To help with this issue, use the following in workflows
# This allows a subsequently queued workflow run to interrupt previous runs
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.run_id}}
cancel-in-progress: true
When a workflow is triggered via a pull request, it will cancel previous running workflows for that
pull request. This is especially useful when changes are pushed to a pull request frequently.
Manually triggered workflows, workflows that run on a schedule, and workflows triggered by pushes to
main are unaffected.