• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Issue Mass update git remote-url

tsaya

New Pleskian
Server operating system version
Rocky Linux 8.10
Plesk version and microupdate number
18.0.81
Bitbucket cloud recently announced this Upcoming change to Bitbucket Cloud SSH access: move from bitbucket.org to ssh.bitbucket.org - Atlassian ,

we have 300 repositories and need to update remote urls . I tried on one domain and repo using cli like this

Code:
plesk ext git --update -domain mydomain.tld -name mydomain.git   -remote-url [email protected]:myaccount/myrepo.git

Code:
The repository "mydomain.git" was updated.

but nothing changes in UI . Has any body found solution/workaround to this issue ?
 
Hi,

I haven’t tested this on Plesk 18.0.81, so please try it on a single repo first.

First, check what the repository itself has stored (the default path is assumed, adjust it if yours differs):

Code:
for d in /var/www/vhosts/*/git/*.git; do echo "$d: $(git --git-dir="$d" config --get remote.origin.url)"; done

If this already shows the new URL, the CLI update worked and the UI is probably showing a stored value that doesn’t get refreshed. If it still shows the old URL, the CLI only changed Plesk’s own record.

If you want to change all repos directly in the git config, this prints the planned changes. Uncomment the last command to apply them:

Code:
for d in /var/www/vhosts/*/git/*.git; do
u=$(git --git-dir="$d" config --get remote.origin.url)
case "$u" in
[email protected]:*)
echo "$d: $u -> [email protected]:${u#[email protected]:}"
# git --git-dir="$d" config remote.origin.url "[email protected]:${u#[email protected]:}"
;;
esac
done

If you run it as root, check the ownership of <REPO>/config afterwards (ls -l) and reset it to the domain’s system user if needed. Don’t forget that ssh.bitbucket.org must be in known_hosts of each system user, otherwise fetch/deploy fails on the host key check. Verify the fingerprint against Atlassian’s published keys before accepting it. I don’t know where the UI reads its value from, so if it still shows the old URL after this, it’s worth asking Plesk support.

Regards
Tessa
 
Hi,

I haven’t tested this on Plesk 18.0.81, so please try it on a single repo first.

First, check what the repository itself has stored (the default path is assumed, adjust it if yours differs):

Code:
for d in /var/www/vhosts/*/git/*.git; do echo "$d: $(git --git-dir="$d" config --get remote.origin.url)"; done

If this already shows the new URL, the CLI update worked and the UI is probably showing a stored value that doesn’t get refreshed. If it still shows the old URL, the CLI only changed Plesk’s own record.

If you want to change all repos directly in the git config, this prints the planned changes. Uncomment the last command to apply them:

Code:
for d in /var/www/vhosts/*/git/*.git; do
u=$(git --git-dir="$d" config --get remote.origin.url)
case "$u" in
[email protected]:*)
echo "$d: $u -> [email protected]:${u#[email protected]:}"
# git --git-dir="$d" config remote.origin.url "[email protected]:${u#[email protected]:}"
;;
esac
done

If you run it as root, check the ownership of <REPO>/config afterwards (ls -l) and reset it to the domain’s system user if needed. Don’t forget that ssh.bitbucket.org must be in known_hosts of each system user, otherwise fetch/deploy fails on the host key check. Verify the fingerprint against Atlassian’s published keys before accepting it. I don’t know where the UI reads its value from, so if it still shows the old URL after this, it’s worth asking Plesk support.

Regards
Tessa

Here's a small addendum to my previous post, in case you're interested in where the UI reads its data from:

The Plesk UI doesn’t read from the repository’s git config. It reads from the SQLite database of the Git extension, located at /usr/local/psa/var/modules/git/git_db.db, in the table Repositories. A Plesk KB article shows that each row there holds the remote URL (e.g. [email protected]:repo/repo.git) and that the table can be queried with the sqlite3 client: https://support.plesk.com/hc/en-us/articles/12376956339479

I haven’t verified this on a live server, and I don’t know the exact name of the URL column, so please check the schema first and test on a single repo.

Backup and schema:
Code:
cp -a /usr/local/psa/var/modules/git/git_db.db /usr/local/psa/var/modules/git/git_db.db.backup
sqlite3 /usr/local/psa/var/modules/git/git_db.db ".schema Repositories"

List the affected entries. The column containing the bitbucket URLs is the one you want:
Code:
sqlite3 /usr/local/psa/var/modules/git/git_db.db "select * from Repositories where instr(remoteUrl, 'bitbucket.org') > 0;"

If the column is named differently, replace remoteUrl with the name from the schema. Then test the update on a single repo first. Placeholder in capitals:
Code:
sqlite3 /usr/local/psa/var/modules/git/git_db.db "update Repositories set remoteUrl = replace(remoteUrl, '[email protected]:', '[email protected]:') where id = REPO_ID;"

If that works, update all of them:
Code:
sqlite3 /usr/local/psa/var/modules/git/git_db.db "update Repositories set remoteUrl = replace(remoteUrl, '[email protected]:', '[email protected]:') where remoteUrl like '[email protected]:%';"

Afterwards:
The git config of each repo still has to be changed separately (see my loop above), otherwise Plesk keeps pulling from the old URL.
ssh.bitbucket.org must be in the known_hosts of each system user.
Verify the host key fingerprint against Atlassian’s published keys before accepting it.

Regards
Tessa
 
Back
Top