Skip to content

fix: re-sync SSH deploy keys when updating site source control#1083

Open
urufudev wants to merge 3 commits into
vitodeploy:3.xfrom
urufudev:fix/ssh-key-resync-on-source-control-update
Open

fix: re-sync SSH deploy keys when updating site source control#1083
urufudev wants to merge 3 commits into
vitodeploy:3.xfrom
urufudev:fix/ssh-key-resync-on-source-control-update

Conversation

@urufudev
Copy link
Copy Markdown

When a user updates the Source Control provider/token for an existing site (via Settings → Source Controls), the SSH deploy key is not automatically re-registered in the repository. This leads to Permission denied (publickey) errors during subsequent deployments.

This PR updates UpdateSourceControl.php to:

  1. Remove the old deploy key from the previous source control provider (if it exists).
  2. Register the existing SSH key with the new source control provider/token.
  3. Store the new deploy_key_id in type_data to ensure DeleteSite can correctly clean it up later.

Changes:
Modified app/Actions/Site/UpdateSourceControl.php to include the logic for deleting the old key and creating the new one using the existing Site and SourceControl providers.

Verification:

  1. Tested on local and production (DigitalOcean) servers.
  2. Verified that keys are correctly created in GitHub with the expected {domain}-key-{id} format.
  3. Verified that the previous key is removed before creating the new one to avoid clutter.

@saeedvaziry
Copy link
Copy Markdown
Member

@urufudev thanks for the PR. I'd appreceate test coverage for this

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Fixes deploy-key drift when a site's Source Control provider/token is changed: the old provider's deploy key is removed and the existing site SSH key is re-registered with the new provider, with the resulting deploy_key_id persisted in type_data so DeleteSite can clean it up later.

Changes:

  • In UpdateSourceControl::update, attempt to delete the previous deploy key, swap source control (and unset the cached relation), then re-register the SSH key on the new provider and store the new deploy_key_id.
  • Failures in the old-key deletion and new-key registration are caught and logged via Log::warning rather than aborting the update.
  • Adds three feature tests covering old-key deletion, new-key registration, and resilience when the old-key deletion fails; also makes minor formatting-only edits to existing tests.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
app/Actions/Site/UpdateSourceControl.php Adds delete-old / re-register-new deploy key logic around the existing source control swap, with try/catch + logging.
tests/Feature/SitesTest.php Adds three tests for the new behavior; also reformats Http::fake calls and arrow-function spacing in existing tests.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +31 to +43
try {
if ($site->sourceControl && isset($site->type_data['deploy_key_id'])) {
$site->sourceControl->provider()->deleteDeployKey(
$site->type_data['deploy_key_id'],
$site->repository,
);
}
} catch (Throwable $e) {
Log::warning('Failed to delete previous deploy key during source control update', [
'site' => $site->id,
'error' => $e->getMessage(),
]);
}
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.

3 participants