Note: I only confirmed that this works fine in a test environment, but I'd like to see it work on the next deployment migration. Thus it's a draft until then. Feedback is still welcome of course :)
While restructuring a Wordpress monorepo deployment, we had the issue that
batou cloned from /srv/s-service/deployment to /mnt/nfs/shared/project
we deployed the new structure that did a git clone of Wordpress from a GitLab rather than a local path
batou noticed that the remote URL was different and threw the old checkout away before cloning the new one rather than pulling.
Normally, this wouldn't be an issue, but wordpress stores state inside the checkout, e.g. in /wp-content/uploads and this was gone. Not a big deal when you have backups, but an automatic migration path is nicer.
This patch introduces a very basic building block for that, a component that ensures that a given git checkout has a given remote with a given name & url.
ensures that the repository under /path/to/repo has a remote called origin that points to git@github.com:nixos/nixpkgs.
This fails if the directory doesn't exist or if it isn't a git repository. For cloning, you still need to use Clone from batou or GitCheckout from batou_ext.
However, in the case described above, this shouldn't fail if the checkout doesn't exist at all: in that case there's no existing repository to "migrate", but it's a fresh deployment that should run through. For that, the component can be skipped if no repo exists at all like this:
Note: I only confirmed that this works fine in a test environment, but I'd like to see it work on the next deployment migration. Thus it's a draft until then. Feedback is still welcome of course :)While restructuring a Wordpress monorepo deployment, we had the issue that
/srv/s-service/deployment
to/mnt/nfs/shared/project
git clone
of Wordpress from a GitLab rather than a local pathNormally, this wouldn't be an issue, but wordpress stores state inside the checkout, e.g. in
/wp-content/uploads
and this was gone. Not a big deal when you have backups, but an automatic migration path is nicer.This patch introduces a very basic building block for that, a component that ensures that a given git checkout has a given remote with a given name & url.
I.e.
ensures that the repository under
/path/to/repo
has a remote calledorigin
that points togit@github.com:nixos/nixpkgs
.This fails if the directory doesn't exist or if it isn't a git repository. For cloning, you still need to use
Clone
from batou orGitCheckout
frombatou_ext
.However, in the case described above, this shouldn't fail if the checkout doesn't exist at all: in that case there's no existing repository to "migrate", but it's a fresh deployment that should run through. For that, the component can be skipped if no repo exists at all like this: