Skip to content

CI lockfile semantics: fail on missing lock + replace CI env-var with explicit command/flag (breaking, next major) #516

@Kamirus

Description

@Kamirus

mops install in CI today auto-detects CI=1 and switches the default --lock from update to check, but silently skips integrity if mops.lock is missing. This is the opposite of what npm ci and cargo build --locked do — both fail loudly. A contributor who never commits mops.lock (or deletes it) gets a green CI build that resolves a fresh dependency graph, defeating the purpose of the lockfile.

Two related changes, ship together in the next major:

  1. Fail loudly when the lockfile is missing in strict mode — match npm ci / cargo --locked.
  2. Drop the CI env-var auto-detection. Replace it with an explicit user choice — either a --frozen / --locked flag (cargo style) or a separate mops ci subcommand (npm style). Env-var magic is fragile (e.g. direnv setting CI=1 locally silently changes mops behavior).

Breaking change — defer until the next major version bump.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions