Skip to content
Use this GitHub action with your project
Add this Action to an existing workflow or create a new one
View on Marketplace

Latest commit

 

History

19 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Moonlit

setup-moonlit

Install the Moonlit CLI in a GitHub Actions workflow.

- uses: actions/checkout@v7
  with:
    fetch-depth: 0
- uses: wolfware-labs/setup-moonlit@v1
- run: moonlit run
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Works on ubuntu-* and macos-* runners, and on x86-64 windows-* runners. Moonlit does not publish an aarch64-pc-windows-msvc build, so windows-11-arm is not supported.

Inputs

Input Default Description
version latest latest, or an exact version such as 1.2.0. Semver ranges are not supported. If the version actually installed does not match an exact request, the action fails — this is its main correctness guarantee.
cache true Cache the Moonlit plugin content directory between runs.
cache-dependency-path release.y*ml Glob whose matched files key the plugin cache.

Outputs

Output Description
version The version actually installed.
bin-dir The directory added to PATH.
cache-dir The resolved plugin cache directory for this runner OS.
cache-hit 'true' on an exact cache key match, 'false' on a partial hit against a restore-keys prefix, or '' when caching was off or skipped.

Run a release pipeline

name: Release

on:
  push:
    branches: [main]

permissions:
  contents: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - uses: wolfware-labs/setup-moonlit@v1
      - run: moonlit run
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

fetch-depth: 0 matters: pipelines that read commit history to decide a version need the full history, and a shallow clone silently gives them the wrong answer.

Validate the pipeline on pull requests

name: Validate pipeline

on:
  pull_request:
    paths: ['release.yml', 'release.yaml']

permissions:
  contents: read

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: wolfware-labs/setup-moonlit@v1
      - run: moonlit validate

Private plugins

The action does not log in to a registry. Add a step:

- uses: wolfware-labs/setup-moonlit@v1
- run: moonlit login --token "$MOONLIT_TOKEN"
  env:
    MOONLIT_TOKEN: ${{ secrets.MOONLIT_TOKEN }}

How it installs

With the default version: latest, the action downloads and runs Moonlit's official cargo-dist installer script (moonlit-installer.sh / .ps1) from the latest GitHub release, piping it into sh (or Invoke-Expression on Windows) on the runner, with the job's secrets in scope. The installer carries per-target sha256 checksums that are embedded into it at release build time, and it verifies the downloaded archive against them before installing — so the binary that lands on PATH is exactly the one the release produced. Those checksums pin the archive given that installer script; they do not pin the script itself. Passing an exact version: (rather than latest) fetches the installer from that specific tagged release, which pins the installer script too, instead of tracking whatever latest resolves to at run time.

Caching

The plugin content store is cached automatically, keyed on the runner OS and a hash of the files matched by cache-dependency-path. Put setup-moonlit after actions/checkout; before it, no config file is visible and caching is skipped with a log line saying so.

Moonlit's plugin store addresses plugin content by sha256, so a stale content entry is a cache miss, never a wrong plugin. That guarantee does not extend to the store's refs/*.json files, which cache a mutable tag's resolution to a digest for 15 minutes. actions/cache saves and restores the whole store directory, so a job that starts within 15 minutes of the run that primed the cache can resolve a mutable plugin tag to whatever digest was seen back then, instead of re-querying the registry.

Set cache: 'false' to turn it off.

Versioning

@v1 tracks the latest v1 release and picks up fixes automatically. Pin an exact release (@v1.2.3) or a commit SHA for byte-exact reproducibility. Releases are cut from Conventional Commits, so a patch or minor release never changes the action's inputs or outputs incompatibly.

Licence

MIT OR Apache-2.0.

About

Install the Moonlit CLI in a GitHub Actions workflow

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors