Files
fleet/.github/workflows
Jordan Montgomery 8ae22b5586 Add npm min release age (#45268)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or
remove if NA -->
**Related issue:** Related to, but does not resolve, #45267

Adds a 12h cooldown period such that when npm is resolving dependencies
it will not resolve anything released less than 12 hours ago. This
doesn't apply globally within the fleet project because some portions
use yarn which #45267 will take care of however this does add it to our
CI jobs and the .npmrc files for projects that use npm

I was going to set this as NPM_CONFIG_MIN_RELEASE_AGE in a github EV but
that won't automatically set it on every runner so leaving it in here
for now

As far as QA local builds and CI are both green. Tested
NPM_CONFIG_MIN_RELEASE_AGE=0.5 and min-release-age=0.5(in npmrc) locally
using the npm package feed https://registry.npmjs.org/-/rss to verify
that recently updated packages either chose an older version OR the
update was blocked if I tried to choose a newer one

# Checklist for submitter

## Testing

- [x] QA'd all new/changed functionality manually


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Enhanced npm supply-chain security by implementing package
installation policies across build workflows and configuration files to
exclude packages released within the last 12 hours.

<!-- review_stack_entry_start -->

[![Review Change
Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45268)

<!-- review_stack_entry_end -->

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-05-13 10:20:13 -04:00
..
2026-05-13 10:20:13 -04:00

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.