Skip to content

fix(scripts): resolve submodule URLs over HTTPS on appliances (NEH-217) - #291

Merged
juancobo merged 1 commit into
devfrom
scripts/neh-217-appliance-https-submodules
Aug 4, 2026
Merged

fix(scripts): resolve submodule URLs over HTTPS on appliances (NEH-217)#291
juancobo merged 1 commit into
devfrom
scripts/neh-217-appliance-https-submodules

Conversation

@juancobo

@juancobo juancobo commented Aug 4, 2026

Copy link
Copy Markdown
Member

Closes the appliance-side submodule access gap from NEH-217, with option (a) from the issue: a config-level rewrite at provisioning, leaving .gitmodules on SSH.

The problem

Appliances have no GitHub SSH key, so git submodule update --init fails with Permission denied (publickey). The Rionegro unit had been worked around by hand-editing .gitmodules to HTTPS — an edit that any branch/tag checkout silently reverts, at which point the next submodule update dies mid-update on a unit with no console. That exact revert-then-fail was hit during the 2026-08-03 update and worked around live with the global rewrite this PR now installs at provisioning.

Changes

  • setup.sh (new step 0b) installs git config --global url."https://github.com/".insteadOf "git@github.com:" as DTK_USER. Config-level rewrites apply after URLs are resolved from .gitmodules, so they survive checkouts; the repos are public, so HTTPS fetches need no credentials. Idempotent.
  • rollback-update.sh runs its git calls with env HOME="$DTK_USER_HOME" (matching how update.sh/setup.sh already invoke cross-user commands), so the rewrite is reliably read when the script runs under sudo.
  • .gitmodules stays SSH — developers keep pushing over SSH with zero workflow change.

Already-provisioned units that will never re-run setup.sh get the same fix as a one-liner (documented in the workspace git-workflow notes): run the same git config --global command as the unit user. Rionegro already has it from the live fix.

Linear: NEH-217 (GitHub mirror #286).

.gitmodules registers the submodules over SSH, which developers need to
push — but appliances have no GitHub key, and the repos are public. The
Rionegro unit was found with .gitmodules hand-edited to HTTPS, an edit any
branch or tag checkout silently reverts, leaving the next
`git submodule update --init` to die mid-update on
"Permission denied (publickey)".

setup.sh now installs the config-level rewrite
(url."https://github.com/".insteadOf "git@github.com:") in DTK_USER's
global git config, which survives checkouts regardless of what
.gitmodules says. rollback-update.sh's git calls gain env HOME= so the
rewrite is read when they run under sudo. .gitmodules stays SSH;
developer workflow is untouched.
Copilot AI review requested due to automatic review settings August 4, 2026 01:17
@linear-code

linear-code Bot commented Aug 4, 2026

Copy link
Copy Markdown

NEH-217

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Configures appliances to fetch public GitHub submodules over HTTPS while preserving SSH URLs for development.

Changes:

  • Adds an idempotent Git URL rewrite during provisioning.
  • Ensures rollback Git commands load the appliance user’s global configuration.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
scripts/setup.sh Installs the appliance-user HTTPS URL rewrite.
scripts/rollback-update.sh Sets the user’s HOME for rollback Git operations.

@juancobo
juancobo merged commit 261cbf5 into dev Aug 4, 2026
1 check passed
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