Moving From Bitbucket To Gitlab
Workflow for moving from Atlassian Bitbucket to our own Gitlab server
August 29, 2016
bitbucket gitlabI like hosting my own stuff. I’m old school. If I can put it somewhere on a system I control, I think that’s 10000% better than putting it out in the ether where someone else controls access to it. Or doesn’t.
We have our company stuff out there. Granted, having it on Bitbucket is better than having it out on Github, where we get to pay for having private repositories. At least Bitbucket gives us private repos for free, but I still fear someone misconfiguring a repository and leaving our junk hanging out on the Internet for anyone to lop off.
I’m also a little sore at Atlassian. We use a lot of their stuff - Confluence, JIRA, HipChat, Bitbucket, Crowd, and I’ve been an Atlassian champion since 2008. Lately, though, I think they’ve turned a corner into a bad alley.
Maybe I’ll write something about that later. For now, let’s just say that they did something with Bitbucket a few days ago that pissed me off, and when a provider pisses me off, I look at how I can break up with them.
I ran Gitlab personally a couple of years ago, and it was great. It was also heavy, so when I moved my personal hosting infrastructure from Iceland to Germany, I decided to drop the Gitlab container. On a whim, I checked back into it and found that the 8.x version is amazing. One of the things I like best about Gitlab (take note, Atlassian), is that they don’t try to be anyone. They don’t worry about anyone else. The tone of their project is a methodical “here is what we do,” and it’s awesome. It doesn’t scream “here is the latest stupid feature so we can compete with Github” – it simply beats you with a spoon on the things that it does.
They even ship their own Docker container! How much easier can it be?
So I rolled it out, moved a couple of repos into it, and I love it. I love having all of the control of everything within it and having it still live in my domain, behind my firewall, with my users.
Basic steps for moving from BB to GL and repointing Jenkins (not all steps will apply):
Gitlab
- create a new project
- import the project from BB (requires oauth configuration)
- edit project
- set to Internal visibility
- change group
- change name (e.g. docker-jenkins -> jenkins)
- rename repository (docker-jenkins -> jenkins)
- disable wiki/issues/snippets
- edit services
- activate JIRA
- edit protected branches
- add default branch (master)
- add webhook if there is a jenkins job
https://{{ jenkins_url }}/project/{{ project_name }}
- set a webhook for all jobs that need notification when the repo changes (
-dev
and-prod
for example). the system will figure out which one needs to fire based on which branch changed.
Jenkins
- change job repository
- uncheck BB build trigger
- add GL build trigger
- enable accept merge request on success (?)
- filter by branch name (master/develop)
- build
- change repo name in build/publish
- change registry url
- change credentials
- remove
force tag replacement
option
- post-build
- remove hipchat notifications
- add slack notifications
- send back gitlab commit update that build passed