nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is it possible to perform path redirection in Stash?

Philip Colmer

I'm looking at Stash to replace our existing git server, which just uses gitweb.

One of the major challenges with such a project would be the fact that the paths to the repositories would change. So, for example, a path at the moment might be something like:

ssh://linaro-private.git.linaro.org/srv/linaro-private.git.linaro.org/repository.git

whereas on Stash, it would be:

ssh://stash.git.linaro.org/project/repository.git

Similarly for git:// and http://URLs.

So my question is this: is there any way that I can set up the server so that if a user tries to pull from an "old" path, it works but gets the code from the "new" path? I'm not so worried about pushes but pulls would be the key thing to address here.

Thanks.

Accepted answers

jhinch (Atlassian)

I would suggest switching your existing server to read-only and mirror the repositories from Stash to the old server. This would allow people to continue to clone/fetch from the original location but as soon as they attempt to push to it they will need to change their remote to Stash.

All comments

Timothy

You might be able to use Apache to rewite the http protocol. I am not sure about the ssh protocol though..

Philip Colmer

Yeah, that had occurred to me, but it needs to be an all or nothing solution.

I wasn't sure if something like soft-links from the "old" path to the "new" path would work (the system is a Linux server). I haven't tried but I suspected that it might not work.

Timothy

I guess this is the pain point for your migration

jhinch (Atlassian)

Svante Gustafsson Björkegren

This was exactly how we did our 400+ repo migration. It worked fine and the users immidiately updated their remotes at their first push.

This approach also gave us some time to re-direct all "systems" using our git repos. We didn't had to move all build-servers, sonar-servers, selenium etc at the time of the migration since they still got the repos from the mirror (10 mintes later though) Now we have migrated most of these as well under more controlled forms.

Cheers,

// Svante

edit: we used the Git Repository Mirror Manager plugin

Philip Colmer

Hi - thanks to you both for sharing this approach.

To make sure I understand what is being suggested, for each of the repos, I need to:

1. Clone the repo from the old server to the new server

2. Use Git Repository Mirror Manager to mirro the repo back to the old server. According to https://bitbucket.org/kostmo/stash-plugins/src/13f28cd3886b901d1c787d0f5203de602bc4edd3/mirror-manager/?at=master, it looks like I also have to do some work on the old server to set up the mirroring.

How do I ensure that when someone pulls the repo from the old server, subsequent pulls and pushes will be to the new server, or does that happen automatically because the new server is mirroring to the old server and therefore overriding the repo config including the repo paths?

I'm struggling to get Git Repository Mirror Manager working but I'll try contacting the developer to see if he can help, even though it says unsupported.

Philip Colmer

I've switched from Git Repository Mirror Manager to Repository Mirror Plugin for Stash (https://marketplace.atlassian.com/plugins/com.englishtown.stash-hook-mirror/versions#b28). It has better documentation and supports SSH keys, which is where I was getting stuck with GRMM.

I'm still struggling, though, to figure out how the repo config gets updated. I've tried following the instructions in https://answers.atlassian.com/questions/54235/importing-an-existing-repository-into-stashand https://confluence.atlassian.com/display/STASH/Importing+code+from+an+existing+projectbut that doesn't sort out the URLs when I do a pull from the old server.

Svante Gustafsson Björkegren

Hi Phil,

This is how we have set it up:

Assumptions:

We are using ssh for protocol
We are using gitolite to manage permissions on our git-server

Create an empty repository in Stash in the correct project via UI or CLI
Clone out a complete copy from your git-server
- git clone --mirror git@git.your-domain:repository-to-be-moved.git
Push up the complete mirror to Stash
- git remote add stash ssh://git@stash.your-domain:7999/<proj>/repository-to-be-moved.git
- git push --mirror stash
Update the permission settings in your original repo on your git-server to grant write permissiions ONLY to the user running the Stash application (e.g. stash) All other users shall be granted Read permissions.
This step is important to avoid updates by users in both replicas.
We are using gitolite on our git-server to manage permisisons and this works well to update permissions this way!
Make sure you have added the public key for your Stash server to the git-server
Enable the Git Repository Mirror Manager for your new Stash repo and update the Mirror Path
Tell all users to updated their remotes if they have cloned the repo originally from the git-server
- git remote set-url origin ssh://git@stash.your-domain:7999/<proj>/repository-to-be-moved.git
Done

This is the procedure I used and it worked in our environment. It assume the approach is workable in any environment with some tweaks added.

Let me know what you think!

Cheers,

// Svante

Philip Colmer

Thanks very much for this, Svante. Absolutely what I was looking for.

The slight downside, and I guess I was hoping too much for it to be automatic, is that users will need to update their remotes :-(. It means that there isn't really any way to essentially force a migration away from the old server to the new one since we are entirely in the hands of the users to update their paths. If they don't do it, they'll continue to pull from the old server.

I guess the only thing that would force them to update their paths would be the fact that they couldn't commit to the old server, but an automatic process would have been nice to avoid that pain, but I think that is just a limitation of how the git tools work.

Thanks again.

Philip

Svante Gustafsson Björkegren

I understand you! But I don't see this as an issue, actually. If a user is continuing to pull from the git-repo that would be ok (with a slight lag of course) and as you point out when they try to push they will receive a permission error which they themselves can correct very easy.

This is a consequence of a distributed version control system. It is hard to centrally control the distributed clones. The pros outweigh the cons, though :-)

Cheers,

// Svante

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server

bitbucket-administration