Skip to content

Comments

fix(install): support case when repo is already cloned#11

Merged
thomasboni merged 1 commit intomainfrom
fix-install
Feb 18, 2026
Merged

fix(install): support case when repo is already cloned#11
thomasboni merged 1 commit intomainfrom
fix-install

Conversation

@thomasboni
Copy link
Contributor

No description provided.

@cursor
Copy link

cursor bot commented Feb 18, 2026

PR Summary

Low Risk
Low risk: small installer logic change to reuse/update an existing clone, plus a Helm chart version bump; main risk is unintended behavior if the existing directory is not a valid git repo.

Overview
Improves install.sh so rerunning the installer no longer fails when plumber-platform already exists: it now cds into the directory and attempts a fast-forward git pull instead of always cloning, and updates the success messaging accordingly.

Bumps the Helm chart version/appVersion in charts/plumber/Chart.yaml from 1.0.3 to 1.0.4.

Written by Cursor Bugbot for commit ff41c4d. This will update automatically on new commits. Configure here.

@thomasboni thomasboni marked this pull request as ready for review February 18, 2026 16:01
@thomasboni thomasboni merged commit 9f47f80 into main Feb 18, 2026
3 checks passed
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

if [ -d "$REPO_DIR" ]; then
echo "Directory ${REPO_DIR} already exists, updating..."
cd "$REPO_DIR"
git pull --ff-only || true
Copy link

Choose a reason for hiding this comment

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

Silent git pull failure shows misleading success message

Medium Severity

git pull --ff-only || true silently swallows all failures — including the case where the directory isn't actually a git repo, the remote is unreachable, or branches have diverged — and the script then prints a green "✓ Repository ready" message. The user has no indication the update failed and may proceed with stale or incorrect files. Since subsequent steps depend on repo contents (scripts/preflight.sh, versions.env), this can cause confusing downstream failures.

Additional Locations (1)

Fix in Cursor Fix in Web

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.

1 participant