Development Infrastructure Update

Hi everyone!

We are moving our development infrastructure from a self-hosted Git service (at nl.git.xonotic.org) to a third-party hoster.

This will enable more collaboration, as well as better and faster code reviewing than our current infrastructure (thanks to a great diff view, review comments features, and more), and thus will greatly improve the development experience. I will even get to review samual/weapons piece by piece with it!

Check it out at:

https://gitlab.com/groups/xonotic

What does this mean for you all?

• If you have commit access to part of our repository:
  • Please create an account at gitlab (if you already have a Google, Twitter or Github account, you may skip this step and log in through these services instead).
    
  • Click your user icon in the top right, then Settings, then SSH keys. Upload your SSH key there.
    
  • Visit https://gitlab.com/xonotic/xonotic/issues/new and create an issue requesting access. Be sure to include the label "Repository Access".
    
  • In one week (on Friday, Aug 29), I will turn off push access to the old server, and enable your user accounts to push to gitlab. The exact procedure for reconfiguring your Git clients will be posted at a later time, but it should boil down to running "./all update -p" twice in a row after the switchover.
    
• If you don't have commit access, "./all update" will handle all necessary transitioning. No extra work for you to do. It might fail once - in which case you should just run it again.
  
• Issues and Wiki currently stored on dev.xonotic.org will not get lost, however, will be frozen in a read-only state. All data that can be ported will be ported. Formatting and issue status will be preserved as much as possible, however, the posts will unfortunately not be associated with your user profile.
  
• We will still keep a copy of all data for backup reasons, and because it's cheap to do. The mirror de.git.xonotic.org will stay up.
  

Have fun, and happy hacking! Reply

+1 Reply

Thanks for the info, I wasn't fully aware of what was going on. And thanks for picking a FLOSS webapp, that's awesome.

Will you answer questions in this thread? I have a few.

About mirrors:
1. What git servers does that leave us with? IIRC we had trouble with the US mirror, so I suppose it has been taken down. That leaves gitlab and de.git. Is de.git read-only now?

About hosting:
2. Is there any cost for hosting on gitlab's servers? Do we know if that cost will evolve over time?
3. Did you consider running our own instance of gitlab? Any reason we didn't go with that? If in the future we were to opt for this, can the move be done conveniently?

About the tracker:
4. You say posts that are ported over from redmine won't belong to our user accounts. That's completely understandable. Can you still put whatever data that would otherwise be lost (username, timestamp?) as a prefix to the text of the messages so that we can still get a clue from this?
5. Does gitlab provide a similar wiki capability, or do we have to start over? Starting over wouldn't be very bad news if we can archive what we've had so far somewhere safe, on a static mirror or something like that. Reply

Thanks for the info, I wasn't fully aware of what was going on. And thanks for picking a FLOSS webapp, that's awesome.

Will you answer questions in this thread? I have a few.

About mirrors:
1. What git servers does that leave us with? IIRC we had trouble with the US mirror, so I suppose it has been taken down. That leaves gitlab and de.git. Is de.git read-only now?

That leaves gitlab and de.git.xonotic.org as mirrors. The US mirror was broken for ages and can be considered gone.

The mirrors always were read-only. Pushing always goes to the authoritative server (in the past in the Netherlands, soon at Gitlab).

About hosting:
2. Is there any cost for hosting on gitlab's servers? Do we know if that cost will evolve over time?

Gitlab provides this as a free service.

3. Did you consider running our own instance of gitlab? Any reason we didn't go with that? If in the future we were to opt for this, can the move be done conveniently?

I did consider it, however, it is about administration time cost. I'd prefer someone else to manage this to stay away from administration pain. The git repo was "okay" regarding this (but its configs would need to be rewritten for an upgrade to a newer version), but redmine... PLEASE NOT.

If we later want to migrate to our own instance, we can - even including the users - if we write our own migration script (there unfortunately is no existing one, but there is a full featured API that can do this). Running our own gitlab especially would mean we get a "sudo" like functionality that would allow for creating issues under the name of another user.

About the tracker:
4. You say posts that are ported over from redmine won't belong to our user accounts. That's completely understandable. Can you still put whatever data that would otherwise be lost (username, timestamp?) as a prefix to the text of the messages so that we can still get a clue from this?

Exactly that is the plan.

5. Does gitlab provide a similar wiki capability, or do we have to start over? Starting over wouldn't be very bad news if we can archive what we've had so far somewhere safe, on a static mirror or something like that.

There is a wiki, and I also want to import its data. The catch is that I will need to convert from Textile to Markdown, which means some formatting may get lost. Once detected, we can fix that manually then. Reply

Thanks for the answers, this seems promising. I'm looking forward to using gitlab. Reply

I'm looking forward to this! Hooray. Reply

What of old and/or "un pushed" local branches, would i need to push those or will they survive the transition anyway? Reply

Don't take my word for it, but I don't think this should affect your local clones at all, unless the ./all script does it. But git itself is pretty much remote-agnostic. Reply

Yeh thats what i *think* too but id rather be sure Reply

Thanks for not using GitHub! Reply

Unpushed branches will of course survive the transition. Reply

The move has happened:

- Pushing has moved - please run the following commands:

Code:

./all update
./all update
./all keygen
./all update -p

The first one is allowed to fail.

- Issues have been ported from Redmine.

- Wiki will be ported later.

- dev.xonotic.org is currently in read-only mode and will stay so. Will soon get replaced by a totally static copy of all issues and wiki. Reply

Ah, maybe it's worth noting that the static mirroring means the urls aren't exactly the same (.html suffix, ? becoming @, and others?) so links to issues require a .html added at the end to work. Perhaps url rewriting on just the issue links would be helpful there. Reply

This looks interesting and good, looking forward to getting started with it in a few months.


P.S. Travels are going well, though I'm keen to get back into Xonotic whenever possible. Reply

On a side note, update -p might ask to authorize gitlab.com, in which case one can compare the public key fingerprint here:
https://about.gitlab.com/gitlab-com/ Reply

I could be be wrong, but I'm pretty sure you can't update a MySQL table with let alone HTML, you need a server-side scripting language to assist you ie. PHP, ASP..

Someone correct me if I'm wrong. Reply

I could be be wrong, but I'm pretty sure you can't update a MySQL table with let alone HTML, you need a server-side scripting language to assist you ie. PHP, ASP..

Someone correct me if I'm wrong.

Taken verbatim from

Code:

http://forum.valhallalegends.com/index.php/topic,17399.msg177156.html?PHPSESSID=8b7c0f91991038b2628594e68285ddd4#msg177156

Spammers are always wrong, so let me correct this. Banned. Reply