8000 fix(install): install on a computer without Docker or KVM access, and run the line again there by adeelahmad · Pull Request #368 · adeelahmad/lense · GitHub
[go: up one dir, main page]

Skip to content

fix(install): install on a computer without Docker or KVM access, and run the line again there - #368

Merged
adeelahmad merged 3 commits into
mainfrom
claude/project-thread-ws42o4
Oct 15, 2026
Merged

adeelahmad merged 3 commits into
mainfrom
claude/project-thread-ws42o4

Conversation

@adeelahmad
@adeelahmad adeelahmad commented Oct 14, 2026 •
Copy link
Copy Markdown
Owner

Requested by Adeel · project thread

Description

Before: the Install workflow ran the one line on runners that already had Docker, and the microsandbox job gave the runner's user KVM itself before installing. The part of install.sh that installs Lens's own prerequisites (Docker from get.docker.com, KVM access) never ran in CI. On a machine whose user install.sh had just added to the kvm group, running the line again in the same session failed: the access setfacl gave lasted only until udev reset it (a VM starting or stopping does), so msb could neither stop the old sandbox nor start the new one. CI didn't notice because install.sh's output was piped into tee, which hid its exit status.

After: the Install from the web installer job takes Docker off the runner first and checks install.sh installed it and Lens came up. The microsandbox job starts with a user who can't use /dev/kvm, checks install.sh installed microsandbox and gave that user KVM, and runs the line again several times in that session. Until the next sign-in makes the kvm group count, install.sh runs every msb command through sg kvm, and the KVM checks count group membership. CI now checks install.sh's own exit status wherever its output goes to tee.

install.sh also installs the acl package where setfacl is missing, quiets a tr: write error it printed, and the installer's server tests wait up to a minute for the fake install on a busy Windows runner.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change; ! in the title)

Checklist:

  • The title is a Conventional Commit.
  • My code follows the code style of this project (make hooks checks it on commit).
  • I added or updated tests. (the Install workflow is the test; shellcheck and actionlint clean)
  • My change requires documentation updates, and I have updated docs/ accordingly. (get-started.md, microsandbox.md)
  • Users need more than the title to understand it, so I wrote it under ## Unreleased in CHANGELOG.md. (n/a)

Done questions (AGENTS.md)

  • Goal: proves the install line installs its prerequisites, and that running it again works in the same session; merged on green CI.
  • Agents: n/a, install path only (the web app's upgrade agent runs the same install.sh).
  • Zero setup: removes the sign-out-and-in step after the installer grants KVM.
  • Fewest clicks and keystrokes: n/a.
  • Configurable: n/a, no new settings.
  • Light: acl is a few hundred KB, only when KVM access is needed.
  • Private and secure: KVM access goes to the installing user only (kvm group, ACL), as before.
  • Cost: n/a.
  • User decides: install.sh still lists what it installs and asks at a terminal.
  • Upgrades: n/a, no stored data.
  • Honest: docs say what CI checks.
  • Tests, docs and generated files updated.
  • Open standards; dependencies keep Lens MIT (acl is system tooling, not a Lens dependency).
  • Result reported with evidence; refine later: a runner without Python 3 for the terminal-only path.

🤖 Generated with Claude Code

https://claude.ai/code/session_014Y4mUBxDN6pTR2fykqrfYV

… new one is

The install jobs ran on runners that already had Docker, and the
microsandbox job gave the runner's user KVM before installing, so the
part of the one line that installs Lens's own prerequisites was never run.
The web installer job now takes Docker off the runner first and checks
the installer lists it and install.sh installs it; the microsandbox job
starts with a user that can't use /dev/kvm and checks install.sh installs
microsandbox and gives that user KVM itself.

install.sh also installs the acl package where setfacl is missing, so a
minimal system gets KVM for this run without signing out and in.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Y4mUBxDN6pTR2fykqrfYV
@adeelahmad adeelahmad self-assigned this Oct 14, 2026
…n-in

The access setfacl gives lasted only until udev reset it, which a VM stopping does, so running
the line again in the same session couldn't start the sandbox. Until the group counts, the
installer starts it through sg. Also quotes the package list in the Install workflow and gives
the installer's server tests a minute to see the fake install finish on a busy Windows runner.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Y4mUBxDN6pTR2fykqrfYV
msb couldn't stop the running sandbox either once udev reset the access setfacl gave, so running
the line again in the same session left the old sandbox holding the port. Every msb command now
runs through sg while the session predates the group. CI checks install.sh's own exit status
where its output is piped into tee, which hid this failure.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Y4mUBxDN6pTR2fykqrfYV
@adeelahmad adeelahmad changed the title ci(install): install on a computer without Docker or KVM access, as a new one is fix(install): install on a computer without Docker or KVM access, and run the line again there Oct 15, 2026
@adeelahmad
adeelahmad merged commit aab0b6e into main Oct 15, 2026
20 checks passed
@adeelahmad
adeelahmad deleted the claude/project-thread-ws42o4 branch October 15, 2026 00:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0