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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions