Add MISE_LOCKED in allowedEnv

[JulesClaussen]

What would you like help with?

None

Please share the URL to the organisation you're creating this request for

https://developer.mend.io/github/stoikio

Additional information

We have set MISE_LOCKED=true in all our project, in order to enforce reproducible installation.
The issue is that Renovate cannot update mise lock files due to this. See logs below:

DEBUG: Executing command (branch="renovate/prek-0.x")
{
  "command": "mise lock prek"
}

DEBUG: exec completed (branch="renovate/prek-0.x")
{
  "durationMs": 563,
  "stdout": "! No tools configured to lock\n",
  "stderr": "mise WARN  Failed to resolve tool version list for prek: [/tmp/renovate/repos/github/stoikio/renovate-tests/mise.toml] prek@0.4.4: prek@0.4.4 is not in the lockfile\nhint: Run `mise install` without --locked to update the lockfile\n"
}

Thanks!

[jamietanna]

To confirm, is the locked = true inside the mise.toml? If so, I believe when Renovate executes mise, it'll be using that, so we shouldn't need to set both?

Is the lockfile error that mise is reporting due to it running in locked mode, and therefore it won't update and set the new version for prek?

[JulesClaussen]

Yes to both of your questions. locked = true in the mise.toml to enforce reproducible builds. The lockfile error indeed comes from running in lockfile.
However, it can be overwritten using the MISE_LOCKED=false directly as an environment variable, like MISE_LOCKED=false mise lock

[jamietanna]

(Trying to clarify the behaviour, not super familiar with this in mise)

So, to confirm:

1. mise.toml has locked = true
2. Renovate runs mise lock prek
3. This fails, because mise is expecting the MISE_LOCKED=true alongside the locked = true to make sure it performs a lockfile update?

[JulesClaussen]

Partially correct yes. Mise does not detail everything in their doc to be fair

With locked=true in the lockfile, when you run bump a package in the mise.toml, and runs a simple mise lock, the command will not fail, but not update the lock either. See the warning I have here (I have manually bumped trivy from 0.70.0 to 0.71.0 for example):

$ mise lock
mise WARN  Failed to resolve tool version list for trivy: [~/Documents/code/<my-repo>/mise.toml] trivy@0.71.0: trivy@0.71.0 is not in the lockfile
hint: Run `mise install` without --locked to update the lockfile
→ Targeting 2 platform(s) for ~/Documents/code/<my-repo>/mise.lock: linux-x64, macos-arm64
→ Processing 7 tool(s): prek@... <and other tools>
✓ Pruned 1 stale tool entry from ~/Documents/code/<my-repo>/mise.lock: trivy
mise downloading artifact for lock-time provenance verification: prek-aarch64-apple-darwin.tar.gz
mise downloading artifact for lock-time provenance verification: uv-aarch64-apple-darwin.tar.gz
lock                         uv@0.11.21 macos-arm64                                                                                                           ✔
✓ Updated 14 platform entries (0 skipped)
mise WARN  Failed to resolve tool version list for trivy: [~/Documents/code/<my-repo>/mise.toml] trivy@0.71.0: trivy@0.71.0 is not in the lockfile
hint: Run `mise install` without --locked to update the lockfile

So the tool stays in 0.70.0, and has no entries in the lockfile. Now, running with MISE_LOCKED=false:

MISE_LOCKED=false mise lock
→ Targeting 2 platform(s) for ~/Documents/code/<my-repo>/mise.lock: linux-x64, macos-arm64
→ Processing 8 tool(s): prek@0 ... <some other tools>, trivy@0.71.0
mise downloading artifact for lock-time provenance verification: prek-aarch64-apple-darwin.tar.gz
mise downloading artifact for lock-time provenance verification: trivy_0.71.0_macOS-ARM64.tar.gz
mise downloading artifact for lock-time provenance verification: uv-aarch64-apple-darwin.tar.gz
lock                         trivy@0.71.0 macos-arm64                                                                                                         ✔
✓ Updated 16 platform entries (0 skipped)
                                                                                                                      mise WARN  missing: checkov@3.3.0

[jamietanna]

So would we want to run MISE_LOCKED=false mise lock (or MISE_LOCKED=false mise lock prek), if there's a locked = true in the mise.toml?

[JulesClaussen]

Yes exactly. I guess we would prefer MISE_LOCKED=false mise lock prek in the prek branch specifically, but if package rules group all the packages together, MISE_LOCKED=false mise lock would make more sense. Not sure whether you can mention multiple packages like mise lock prek trivy ...