search

kubitron / redmine_git_hosting

A ChiliProject/Redmine plugin which makes configuring your own git hosting easy.
78 stars 15 forks source link

prevent remote tag deletion on mirrors #47

Closed levelos closed 12 years ago

levelos commented 12 years ago

Currently, any mirror added to a hosted repository has any tags that are in the mirror repo deleted that don't exist in the hosted repo. This is because of the command run to mirror the repos: `git push --mirror [mirror repo url]' by default deletes remote branches.

Not sure the best solution, but one idea would be to add a setting on the mirror of what branch(es) to mirror or to use the current --mirror flag. Maybe there are other ways to prevent remote branch deletion.

The use case we're solving is that we're pushing to a PaaS/hosting provider, in this case Pantheon for Drupal, that generates it's own tags for deployment and we end up overwriting them with mirroring enabled which causes some hairy issues. Thanks for exploring this.

kubitron commented 12 years ago

Hm.... This is tricky, since git doesn't seem to want to push everything unless you use some variant of --mirror. I haven't really played with a lot of variants here. Explicitly stating which branches to push would get annoying fast. I'll think about it.

levelos commented 12 years ago

Maybe just a flag to either use --mirror or select a branch from a select list.

kubitron commented 12 years ago

Well, another option is to replace:

git push --mirror

with:

git push --all --tags --force

This is almost equivalent without the removal of references on the remote (like tags) being deleted.

levelos commented 12 years ago

Sounds even better.

kubitron commented 12 years ago

Are you still around? I have a version that I'm about to put up that would give you a potential fix.

I'm wondering if you would be willing to try? (I'm about to be traveling, so cannot quite post it).

levelos commented 12 years ago

Sure John, I'd be happy to give it a try. Thanks for the great work ...

kubitron commented 12 years ago

Ok. Try pulling from the testing branch.

Edit your mirror and select "Force Update" and "Push all Branches". This should have the behavior your wanted... Let me know if it works and/or has problems.

kubitron commented 12 years ago

Also, let me know if the options are confusing. Hopefully they are self-explanatory if you understand "git push".

kubitron commented 12 years ago

Ping!

Any thoughts on the implementation?

kubitron commented 12 years ago

I fixed a bug in this implementation and pushed it up to the master branch. Hopefully it works for you. I just realized that I pushed it up, then it disappeared (and didn't work anyway, since there was a bug).

Let me know, since I want to close this feature request.

levelos commented 12 years ago

@kubitron, finally giving this a spin, sorry for taking so long. Options look great at first blush, but I can't test. Any change I try to make is triggering a "URL is invalid" error message. My mirrored repo URL is:

git@git.drupal.org:project/redhen_membership.git

kubitron commented 12 years ago

@levelos: Sorry about that. Just put an "ssh://" in front of it... I can make your syntax validate if you think it would be useful.

levelos commented 12 years ago

Thanks, I'll try that. Regardless, I think that syntax should validate as it's what's presented as repo URLs on GitHub, drupal.org, etc.

levelos commented 12 years ago

Couple follow up points.

Using the git protocol in the URL also fails validation. E.g., @git://git.drupal.org/project/redhen_membership.git@ fails and won't let me save the mirror.

When using an HTTP protocol, E.g., http://git.drupal.org/project/redhen_membership.git, I get the following error. The same URL works fine locally for both cloning and pushing using SSH keys.

error: Cannot access URL http://git.drupal.org/project/redhen_membership.git/, return code 22 fatal: git-http-push failed

kubitron commented 12 years ago

Hm... You don't intend to have the '@' in front of 'git', do you? I understand that 'git' urls aren't validated either. Ok. I'll broaden the validation a lot.

As for the second problem, that is weird. Are you sure that you were able to use it in the past? Note that the URL that you use is simply put into a 'git push' command.

levelos commented 12 years ago

Sorry, @git://git.drupal.org/project/redhen_membership.git@ was supposed to be git://git.drupal.org/project/redhen_membership.git. Ideally, git@example.com:project/name will work. Not sure why the http format was failing. Definitely works locally. In the error message, there's an extra slash at the end, so maybe that's a clue. Thanks!

kubitron commented 12 years ago

Ok. Try pulling from my testing branch. I want to see if you can at least create all the mirrors that you want.

Next -- do all the formats fail, or just the http one? Note that I don't believe that http is an ssh protocol. Your server needs to support git over http.

Principle question: Can you at least do what you did before (after pulling the testing branch)? Second question: Selecting "forced" and "all branches", what does and doesn't work?

levelos commented 12 years ago

Ok, that works now. In a /simple/ test, I can use all 3 settings and things at least work as before. To actually ensure that remote tags are not overwritten, I need to test with a production site so will need to do some more testing first. Thanks for working on this John!

kubitron commented 12 years ago

Just to verify -- when you say "all three settings", I'm assuming that you mean "mirroring" or "forced"+"all branches" or "forced"+explicit reference? The validation shouldn't allow you to select "all branches" and "all tags" at the same time, for instance...

Let me know how things work. The "testing" branch has another change which hopefully won't get in your way, namely the ability to use an auxiliary gitolite config file. "out of the box", this should simply act as you are used to it.

levelos commented 12 years ago

I tried mirroring, force + all branches, and unforced + all branches. I didn't test forced + explicit reference. Plans on merging into master? Thanks.

kubitron commented 12 years ago

Have you seen whether it fixes your problems yet? (i.e. did you show that it left your tags alone?).

I am hesitating on merging into master only because I would like to have some validation that the gitolite config patch doesn't screw up my existing users....

levelos commented 12 years ago

I face a challenge there in that I currently only have the abiliy to test that on a production site. The previous setup took the site down, so I'm a bit squeamish :) The functional change does look like it will solve the problem, though.

John Kubiatowicz wrote:

Have you seen whether it fixes your problems yet? (i.e. did you show that it left your tags alone?).

kubitron commented 12 years ago

Sigh. Which setup took down the site? Sorry for that....

levelos commented 12 years ago

No worries at all man, it was my fault. We use a PaaS provider which deploys to dev/test/prod environments based on tag. We were mirroring form Chili to the PaaS repo for dev workflow reasons. The reason I brought this issue up is that setup was wiping the automated tags from the PaaS repo, which caused the wrong code to be deployed. It seems like these changes will prevent that from happening ...

kubitron commented 12 years ago

Ah. So, you haven't been using this plugin since then?

As far as I know, you are the only active requester of this functionality (although it makes sense to have it). I'm not entirely sure how to validate it, then (I like to know that another person out there is using the functionality).

levelos commented 12 years ago

We've been using it, just w/o the mirroring enabled on the projects that we're using the PaaS that relied on tags for deployment. We are, and will continue to use the plugin, and hope to use it for all use cases moving forward. For further validation, though, I really need to setup, or wait, for a project that's still staging to the avoid the risk of a production site going down. If not sooner, I'll setup a dummy environment over the weekend and see if I can't break it ;)

kubitron commented 12 years ago

Thanks. Really appreciate it.

If you really try to break it, that would be good. The testing branch has other changes as well, including removal of the dispatcher as an incremental movement toward Rails 3...

kubitron commented 12 years ago

Ping! Wondering if this issue can be closed yet....

kubitron commented 12 years ago

Waiting on you for an ok before merging into master. Does this patch fix things for you? I would like to freeze new version soon (so can do Redmine 1.4/2.0 integration).

levelos commented 12 years ago

Works for me.

kubitron commented 12 years ago

Did it solve the original problem?

levelos commented 12 years ago

As far as I can tell, yes, thanks!

kubitron commented 12 years ago

Great! I'm going to close it then.

kubitron commented 12 years ago

Incidentally, you might also update to the latest testing branch and try out the deployment credentials (off repository-settings page). Perhaps these would be useful for you as well.... (There is a mention in them in the README for that branch as well). This is the release-candidate for the 0.4.6x release.

--KUBI--