mise 持续集成实战指南用同一份 mise.toml 打通 CI 与本地开发环境【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise 是一个集 dev tools、env vars、task runner 于一体的工具管理器其持续集成CI设计的核心原则是开发环境与 CI 使用同一份mise.toml让两者始终选择同一批工具版本。本文围绕 docs/continuous-integration.md 展开给出可在任意 CI 平台落地的通用方案committed wrapper 引导安装、工具缓存、lockfile 锁定、Safe mode 防护并分别给出 GitHub Actions、GitLab CI、Xcode Cloud 三种具体平台的配置示例。读完你就能把现有流水线从手工安装工具升级为以仓库配置为唯一事实来源的可靠构建流程。核心理念CI 与本地共用同一配置传统 CI 脚本往往各自维护一套工具安装方式容易与本地开发环境产生版本漂移。mise 的做法是让 CI 直接复用仓库根目录下的mise.toml项目配置见 docs/configuration.md用mise exec或mise run任务系统见 docs/tasks/index.md加载这些工具以及项目声明的环境变量CI 中不需要交互式 shell activation——mise exec只影响其内部子进程天然适合非交互流水线为了让安装可复现提交 lockfile 并在 CI 中执行mise install --locked如果流水线还需要控制 mise 自身的升级节奏可以单独固定 mise 的版本见下文MISE_VERSION。从源码看mise exec是 CI 的核心入口其实现位于 src/cli/exec.rs作用是加载当前配置后以新环境执行命令而mise runsrc/cli/run.rs在此基础上还会加载任务定义。两者都不依赖交互式 shell因此无需在 CI 中执行mise activate。通用方案适配任意 CI Provider以下 shell 片段适用于任何能运行 bash 的 CI 平台前提是项目为 Node.js 项目且在mise.toml中声明了 Node已提交package-lock.jsonpackage.json中存在test脚本请把 npm 命令替换成你项目的构建或测试命令runner 上具备curl、CA 证书、tar以及sha256sum或shasum用于下载、校验、解压 mise。set -eu ./bin/mise install ./bin/mise exec -- npm ci ./bin/mise exec -- npm test要点在 runner 上执行 wrapper 时可用MISE_VERSION指定要安装的 mise 版本若仓库提交了 lockfile把./bin/mise install换成./bin/mise install --locked确保按锁定版本安装。Bootstrapping提交一份可自助安装的 wrapper与其在每个流水线里单独做一次安装步骤不如把一份按需安装 mise的 wrapper 提交进仓库。本地用以下命令生成mise generate install-script -l -w参数说明实现见 src/cli/generate/install_script.rs-l/--localize让 wrapper 把 mise 二进制、已安装工具、缓存、状态全部放在项目本地目录.mise/下可用--localized-dir改目录名-w/--write把脚本写到./bin/mise并赋予可执行权限不指定则打印到 stdout-V/--version固定要拉取的 mise 版本--windows额外生成WRITE.cmdWindows 启动器方便在 Windows 上 clone 项目的贡献者要求配合--write使用。生成后把bin/mise提交进仓库并在.gitignore中加入.mise/。安装与执行都走这个 wrapper两条命令才能使用同一套本地目录./bin/mise install ./bin/mise exec -- npm ci ./bin/mise exec -- npm test关于版本与路径的几个细节wrapper 默认使用生成它的那个 mise 版本要更新默认版本就重新生成并提交或在 CI 中设置MISE_VERSIONMISE_INSTALL_PATH可以覆盖二进制存放位置不加-l时wrapper 使用常规 mise 目录二进制默认放在数据目录的bootstrap/子目录下非本地化时bash wrapper 会读取MISE_DATA_DIR并在MISE_INSTALL_PATH未显式设置时把它指向$mise_data_dir/bootstrap/mise-$mise_version旧版本 wrapper 可能复用上一代缓存目录中的二进制重新生成即可迁移到当前的安装行为本地化 wrapper 还会导出MISE_TRUSTED_CONFIG_PATHS指向项目目录、并忽略用户全局配置目录保证项目内隔离不被个人全局配置污染。Caching缓存工具避免每次重下缓存已安装的工具避免每个 job 重复下载cache key 必须包含runner 的操作系统与架构、mise 配置、lockfile使用了不同环境或不同安装选项的 job应使用相互独立的缓存恢复缓存后仍然要执行mise install——它负责补齐缓存中缺失的工具目录位置安装目录与元数据见 directories 文档。缓存只是优化空缓存下 job 也必须能成功。针对不受信配置运行Safe mode当机器人bot需要从 PR 分支解析工具版本时它接触的mise.toml可能是攻击者可控的。此时设置MISE_SAFE1可防止项目配置执行代码或注入环境变量。例如MISE_SAFE1 mise lock --bump --dry-run --json--dry-run用于只预览不落盘机器人需要真正更新mise.lock时移除它Safe mode 会拒绝task 执行、模板exec()、插件安装等需要执行项目代码的操作实现上通过ensure_not_safe()在 src/config/settings.rs 处显式报错它会忽略项目环境变量与项目[settings]并抑制hooks部分 backend如 asdf 这类依赖脚本的在 Safe mode 下无法解析版本操作者拥有的全局配置仍然生效Safe mode 的精确边界与 backend 限制见 docs/security.md。从源码看MISE_SAFE1与全局safe设置都会进入Settings::safe_mode()src/config/settings.rs设置加载完成时读取safe字段未加载时回退到MISE_SAFE环境变量并在解析阶段用缓存值保证判断始终准确。mise lock的--bump --dry-run --json参数实现在 src/cli/lock.rs--bump重新解析选择器、--dry-run不写入、--json输出机器可读结果bot 场景下这是解析版本但不安装工具的典型组合。GitHub Actions官方 mise-action 会安装 mise 以及检出的仓库中声明的所有工具。默认行为缓存工具、把 shims 加入PATH、为后续步骤导出 mise 环境变量。name: test on: pull_request: push: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv6 - uses: jdx/mise-actionv4 - run: mise exec -- npm ci - run: mise exec -- npm test仓库已有mise.lock时在 action 的with块中追加install_args: --locked。相关输入version固定 mise 自身版本working_directory选择子项目mise_toml/tool_versions当某个 workflow 刻意提供自己的配置时使用常规情况下应把工具版本放在仓库配置里缓存与认证相关选项见 action 的 inputs 文档。GitLab CI以下.gitlab-ci.yml使用 Debian 镜像 提交进仓库的 wrapper假设与上面通用示例相同的 Node.js 项目。你的工具所需的系统包可加到before_script或预先构建好带这些包的 CI 镜像。build-job: stage: build image: debian:13-slim cache: key: prefix: mise-debian13-amd64 files: [bin/mise, mise.toml, mise.lock] paths: - .mise/installs/ - .mise/cache/ before_script: - apt-get update apt-get install -y --no-install-recommends curl ca-certificates tar script: - ./bin/mise install - ./bin/mise exec -- npm ci - ./bin/mise exec -- npm run build注意事项示例的 cache prefix 假设 runner 是 amd64其他架构请换用不同的 prefix项目没有 lockfile 就从 key 中移除mise.lock有 lockfile 就把安装命令换成mise install --locked示例要求package.json里有build脚本这里依赖本地化 wrapper 设定 mise 目录缓存路径.mise/installs/、.mise/cache/因此生效。Xcode Cloud在 Xcode Cloud 的 post-clone 脚本ci_scripts/ci_post_clone.sh中安装并运行工具。将生成的 wrapper 提交在bin/mise。以下示例假设仓库的mise.toml中声明了 SwiftLint#!/bin/sh set -eu cd $CI_PRIMARY_REPOSITORY_PATH ./bin/mise install ./bin/mise exec -- swiftlint lint要点提交前先给脚本加可执行权限此脚本中的环境变量修改不会配置后续每个 build phase其他需要 mise 工具的 phase 也要用mise exec本地 Xcode 构建的接入方式见 IDE integration。小结与自查清单落地 CI 时对照以下清单逐项确认开发与 CI 是否共用同一份mise.toml可考虑配合 mise.lock 文档 提交 lockfile是否用mise exec/mise run而非交互式 activation是否提交bin/misewrapper 并在.gitignore中排除.mise/cache key 是否包含 OS/架构、mise 配置与 lockfile且空缓存下 job 依然能成功处理 PR 等不受信配置的自动化任务是否设置了MISE_SAFE1mise 自身版本是否按需用MISE_VERSION/ actionversion固定。按上述方案CI 与本地开发将始终解析到同一批工具版本构建结果可复现、可缓存、可审计。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考