With GitLab 8.16 you can deploy GitLab straight to Google Kubernetes Engine (GKE) and go from Idea to Production in about 20 minutes, with auto-scaling CI, auto deploy, Mattermost, and a private Docker registry all on your own Kubernetes cluster. Watch the complete video tutorial to find out how you can take your team's productivity to the next level.
Note: This article has been moved to our documentation so it can be more easily updated. We recommend using the Azure installation documentation.
GitLab is a scalable, self-hosted Git repository "ecosystem". It is available as a free Community Edition and as a subscription-based Enterprise Edition. If you want to host your own full-featured source control system, under your control, then you should consider GitLab. Spinning up your own instance can be done in just a few hours using the Omnibus packages.
But what if you don't want to invest that much time to see if GitLab is for you? Does Linux scare you? Do you want to try GitLab quickly without a big up-front investment? Need someone else to handle your GitLab administration? Microsoft Azure may be the answer.
Note: we assume you are familiar with GitLab and you wish to have your own GitLab instance on-premises, working in a Virtual Machine.
Note: This article has been moved to a technical article so it can be more easily updated. We recommend using the article.
OpenShift Origin is an open source container application platform created by RedHat, based on kubernetes and Docker. That means you can host your own PaaS for free and almost with no hassle.
In this tutorial, we will see how to deploy GitLab in OpenShift using GitLab's official Docker image while getting familiar with the web interface and CLI tools that will help us achieve our goal.
WARNING StartCom certificates have recently been distrusted by Mozilla Firefox and Google Chrome. Certs issued prior to October 21st, 2016 don't seem to have been affected and are therefore still trusted.
In response to my contact, StartCom affirmed they're working hard to revert this situation and hope to have a resolution by the end of January, 2017.
Update by Marcia Ramos, on 2016/12/20.
With GitLab Pages you can host your static website under your custom domain. With a StartSSL digital certificate you can secure it. And that's all for free!
In this post, first we'll give you a quick overview on SSL/TLS certificates and StartCom CA, then we will show you a comparison between StartSSL Class 1 and Let's Encrypt to facilitate your decision to choose one over another.
Finally, we will guide you through the process of securing your GitLab Pages site with StartSSL Class 1 free certificates.
Note: We assume you are familiar with web development and web hosting.
Our Docker image is a great way to quickly bring up an instance of GitLab. You can use it to try new features, or mount the storage volumes and use it for all your GitLab needs.
It has been over two years since we started thinking about Docker and GitLab together. In those years we have pushed over 100 CE and EE docker images to Docker Hub, and have built new features like GitLab CI with built-in Docker support, helping us (and you!) to test and build our applications easier and faster.
Read on for more details on how we scale GitLab by having Docker built in.
Which Static Site Generators (SSGs) can I use with GitLab Pages? How to set up GitLab CI to build my SSG site? Where can I find some examples?
If these questions ring a bell, this series of posts is for you! We prepared three articles around the same theme "Static Site Generators (SSGs)".
This is Part 3: Build any SSG site with GitLab Pages, where we'll show you some examples of SSGs using distinct GitLab CI configurations, so you can understand it and adjust it to your needs.
Read through the previous posts:
Note: For this series, we assume you are familiar with web development, curious about Static Site Generators, and excited to see your site getting deployed with GitLab Pages.
What are Static Site Generators? What are they for? Why should I use them? Do they have limitations? How can I use them with GitLab Pages?
If these questions ring a bell, this series of posts is for you! We are preparing three articles around the same theme "Static Site Generators (SSGs)".
This is Part 2: Modern Static Site Generators, where we provide you with an overview on the subject.
The previous post was Part 1: Dynamic x Static Websites, where we briefly explained the differences between them, and their pros and cons.
Stay tuned for the next post: Part 3: Build any SSG site with GitLab Pages!
Note: For this series, we assume you are familiar with web development, curious about Static Site Generators, and excited to see your site getting deployed with GitLab Pages.
This post is part of a series Celebrating 1,000 Contributors
GitLab is built on open-source and has a thriving community. We appreciate all of our existing contributors and we look forward to welcoming new contributors, as well. This post is helpful if you've considered developing a feature or fix for GitLab but are unsure how to set up a development environment.
As with any Rails application, GitLab has a few moving parts: a database, Redis, Sidekiq, the Rails application server, GitLab Workhorse, and GitLab Shell. It can be a challenge to configure each of these components on your own. That's why we created the GitLab Omnibus packages for users, recently highlighted in another blog post. Perhaps not as well known is that we also have the GitLab Development Kit (GDK) to improve the experience for developers. In this post we'll go through the steps necessary to get GDK set up on your workstation.
What is the difference between static and dynamic websites? What are the advantages of one over another? Which ones can I use with GitLab Pages? What about Static Site Generators?
If these questions ring a bell, this series of posts is for you! We are preparing three articles around the same theme "Static Site Generators (SSGs)".
This is Part 1: Dynamic vs Static Websites, where we go over their differences, pros and cons.
Stay tuned for the next two posts:
Note: For this series, we assume you are familiar with web development, curious about Static Site Generators, and excited to see your site getting deployed with GitLab Pages.
Yesterday we released GitLab 8.8, super powering GitLab's built-in continuous integration. With it, you can build a pipeline in GitLab, visualizing your builds, tests, deploys and any other stage of the life cycle of your software. Today (and already in GitLab 8.8), we're releasing the next step: GitLab Container Registry.
GitLab Container Registry is a secure and private registry for Docker images. Built on open source software, GitLab Container Registry isn't just a standalone registry; it's completely integrated with GitLab.
GitLab is all about having a single, integrated experience and our registry is no exception. You can now easily use your images for GitLab CI, create images specific for tags or branches and much more.
Our container registry is the first Docker registry that is fully integrated with Git repository management and comes out of the box with GitLab 8.8. So if you've upgraded, you already have it! This means our integrated Container Registry requires no additional installation. It allows for easy upload and download of images from GitLab CI. And it's free.
Read the administration documentation to learn how to enable it on your GitLab instance.
This tutorial is a re-post of Shippable's blog post.
GitLab is a fast-growing choice for enterprises managing their application code and team collaboration both on-premises and in the cloud. Today we are excited to announce Shippable support for application delivery pipelines for GitLab developers.
Shippable now extends GitLab's combination of Git-based source code repositories and enterprise features such as authentication and security with CI/CD pipelines. Shippable connects with GitLab self-hosted community and enterprise editions as well as their cloud offering so we work the way you want to.
A number of people have asked about the infrastructure of GitLab.com. Our passionate and curious Twitter followers inquired specifically about how many servers we use for GitLab.com. Given the number of questions we've gotten on this topic, we wanted to go ahead and offer an inside look at our GitLab.com infrastructure. In this post, you'll find out just how many servers we use. You'll gain some perspective on what those servers are up to.
This tutorial is adapted from the How To Use the GitLab One-Click Install Image to Manage Git Repositories tutorial on DigitalOcean.
Collaborating on projects, keeping track of source changes, and maintaining a clean code repository are some great reasons to use a version control system. Version control is now considered an essential tool in software development.
Git is the most popular distributed version control system. GitLab is a Git repository management server that can be used to host repositories and set up control structures for git within a clean web interface. It is built on Ruby on Rails.
DigitalOcean has created a GitLab application image that can be used to instantly deploy GitLab Community Edition on a DigitalOcean Ubuntu 14.04 x86-64 droplet using the Omnibus installer. You can have your own repository system up and running in minutes.
GitLab has built-in continuous integration to allow you to run a number of tasks as you prepare to deploy your software. Typical tasks might be to build a software package or to run tests as specified in a YAML file. These tasks need...
In the past 8 months gitlab-workhorse, a 'weekend project' written in Go instead of our preferred Ruby, grew from a tiny program that addressed git clone timeouts into a critical component that touches almost all HTTP requests to GitLab. In this blog post I will reflect on how we got here.
In this post we will talk about HTTPS and how to add it to your GitLab Pages site with Let's Encrypt.
Not only is Continuous Integration built-in with GitLab CE and EE, but we also offer Shared Runners to run your builds in CI for free on GitLab.com. Up until recently, you may have experienced a short wait time as your build got queued for a shared runner. With the latest release of GitLab Runner 1.1, we've introduced autoscaling to help us meet the growing demand, and this is now available on GitLab.com. Less waiting, more building!
With GitLab Pages you can host your static website for free. We added GitLab Pages in GitLab Enterprise Edition (EE) 8.3, and then added support for custom domains and TLS certificates in GitLab EE 8.5. We made this service freely available to users on GitLab.com, which is our hosted GitLab EE service, offering unlimited and free public or private projects.
We've since added some great resources to help you get started, including this handy quickstart guide.
Two years ago we announced that GitLab is now simple to install to great triumph. Since then, GitLab has grown to become an irreplaceable tool for many professionals. Part of this success can certainly be credited to an easier installation process using the omnibus-gitlab packages. The packages, however, seem to have polarized people to either love them, or hate them.
Let's take a look at what kind of decisions we need to make on every release of GitLab and how omnibus-gitlab package fits into this process.
GitLab 8.6 will ship with improved search performance for PostgreSQL thanks to the use of trigram indexes. In this article we'll look at how these indexes work and how they can be used to speed up queries using LIKE conditions.
In GitLab, everything you do can be cross-linked and referenced. This improves discoverability and reduces duplicate effort.
GitLab is more than just a Git repository manager. There are a number of tools to help you collaborate with others, or even just manage a project yourself. The best features of GitLab help you link and reference related work.
Sign up for our webcast! Find out more about making the most of GitLab to collaborate on your projects, join us for our GitLab Intro webcast on GitLab Workflow, Thursday March 10th.
There are many cloud-based continuous integration (CI) providers out there and most of them generously offer free plans for open-source projects. While this is great for the open-source community, paid plans can get a little bit too expensive for small start-ups that would prefer to keep their source code private. In such an ecosystem, GitLab Inc. stands out as a viable option with unlimited private repositories and its GitLab Runner, a free and open-source tool to automate the testing and building of projects, thus giving software developers the freedom to experiment with different approaches to build the optimal pipeline for their needs.
This tutorial will demonstrate how to get started with a CI workflow using GitLab Runner. We will first set up a sample NodeJS project hosted on Gitlab.com to run tests on build machines provided by GitLab Inc. Then, we will set up and configure our own specific runner on a private server. Finally we will go over some good practices to speed up the build time as the project grows. By the end of this tutorial you will feel comfortable building your own CI solution, custom-tailored for your existing projects. This post will be useful for project managers looking for affordable CI solutions and developers wanting to build test-driven and sustainable software projects.
In GitLab 8.5 we shipped numerous performance improvements. In this article we'll take a look at some of these changes and the process involved in finding and resolving these issues. In particular we'll look at the following merge requests:
Have you ever tried to push changes to GitLab and gotten the error “port 22: Connection refused"? The network you're connected to doesn't allow using port 22 and you suddenly can't get your work done. I want to push and I want to push now!
You'd be happy to know that GitLab.com now runs an alternate git+ssh port (443) which you can use whenever you are in a place where port 22 is blocked.
Sometimes it's easier to make quick changes directly from the GitLab interface than to clone the project and use the Git command line tool. In this feature highlight we look at how you can create a new file, directory, branch or tag from the file browser. All of these actions are available from a single dropdown menu.
This is the start of a series of posts to get you started with GitLab and GitLab CI.
In this first post, we will explain what CI is, why you would use it, and we will briefly explore a higher overview of the components that make GitLab and GitLab CI work together.
Let's dive in!
This is a guest post by CoreOS.
The proliferation of containerization via systems such as Docker and rkt has introduced many benefits for application developers worldwide. However, this trend towards running applications in containers has also introduced hurdles when trying to ensure continuous integration of applications. Developers who depend upon continuous integration are faced with a new problem: How to ensure they always have a fully up-to-date container image of their source code, built every time they push to source control, and, available in their container registry immediately.
To help developers be more efficient working in teams and ensure they are developing on the most up-to-date version of their container images, we at Quay.io developed a continuous building pipeline. Quay.io transforms source code found in GitLab and other SCMs into Docker container images on every push. Quay.io, delivered by CoreOS, is a secure and easy way to build, manage, store and serve Docker container images.
By bringing Quay.io together with GitLab, users are able to develop easier and faster thanks to seamless syncing of their code to container images, helping to identify problems more quickly and easily test their updated container images in response to changes.
If you want keep code quality high, it is important that you use a code review process. In GitLab, the best way to do this is by using Merge Requests.
We created merge requests so that only a person with the required permission (developer or higher) can merge code into the target branch. If you want more people to review code before it's merged, you can now do this with Merge Request Approvals in GitLab Enterprise Edition.
Note: this is a follow up to our previous feature highlight on approvals, since we've added additional functionality in GitLab 7.13
We just wrote some new documentation on how Gitlab uses Unicorn and unicorn-worker-killer, available on doc.gitlab.com but also included below. We would love to hear from the community if you have other questions so we can improve this documentation resource!
GitLab.com suffered an outage from 2015-05-29 01:00 to 2015-05-29 02:34 (times in UTC). In this blog post we will discuss what happened, why it took so long to recover the service, and what we are doing to reduce the likelihood and impact of such incidents.
We're working on a version check function for GitLab to reduce the problem of outdated servers. These servers are a security problem, provide a bad user experience and lead to issues being created with problems that have already been solved. By making outdated installations visible to its users we hope that people will upgrade sooner.
GitLab CI Multi-purpose Runner is yet another CI runner, but this time written in Go with a vast number of features that leverage all the latest technologies. It's an unofficial project made by me, Kamil Trzciński, with love for GitLab CI to help aid some problems with current runner and make the use of CI really simple and secure.
At GitLab B.V. we are working on an infrastructure upgrade to give more CPU power and storage space to GitLab.com. (We are currently still running on a single server.) As a part of this upgrade we wanted to move gitlab.com from our own dedicated hardware servers to an AWS data center 400 kilometers away. In this blog post I will tell you how I did that and what challenges I had to overcome. An epic adventure of hand-rolled network tunnels, advanced DRBD features and streaming 9TB of data through SSH pipes!
Want to get your first own GitLab instance running? We're here to help!
This is what you need to do:
GitLab has a very active development cycle with many features being added to its monthly release by more than 700 contributors. Like many projects it has a changelog file that details all significant new features, bugfixes and changes to behaviour. Every pull/merge request author is encouraged to add a line to this changelog. Unfortunately, the amount of merge requests lead to a time-consuming problem.
When developing software you are usually spoiled for choice. There are many languages you can choose from, different test suites to try, countless frameworks you can use and many Continuous Integration (CI) offerings.
You can always go with the language you like the most, the test suite you find most practical and choose not to use a framework, but you should always think about CI.
Continuous Integration is a way to increase code quality without putting an extra burden on the developers. Tests and checks of your code are handled on a server and automatically reported back to you.
Here are out top 7 reasons why we think you should be using CI and why you should consider it from the beginning of your project.
The last thing you want to happen is having problems on your server due to your logs. You need them to debug problems, not cause them. With large GitLab instances, it's a great idea to ship your logs to a separate server. This way, they are easier to manage and you don't need to worry about space. But by using TCP to send the logs you risk a connection failure and subsequent problems with your instance.
Therefore, with GitLab Enterprise Edition (7.1 and up) Omnibus packages, we introduced UDP log shipping. As opposed to TCP, UDP doesn't care about whether packets get received, it keeps sending them in a non-blocking, fire-and-forget manner. That makes UDP really fast, lightweight and if you log server crashes, it won't affect your GitLab instance. UDP doesn't care.
Back in February of this year, we radically simplified the installation process of GitLab with the first release of our Omnibus packages for GitLab. Today we are excited to announce that our Omnibus packages now include the GitLab CI Coordinator.
To start using GitLab CI on your GitLab server you need to take the following steps:
ci.example.com;/etc/gitlab/gitlab.rb:# External URL to reach the GitLab CI Coordinator at
ci_external_url 'http://ci.example.com'
Then run sudo gitlab-ctl reconfigure and you have a CI Coordinator running on your GitLab server, integrated with GitLab!
Gitolite was a real help when we started with GitLab. It saves us a lot of work and provide a pretty functional solution.
But after time we understood - keep gitlab and gitolite synced is harder than build own solution.
For the past couple of days I've been working on the production environment for Gitlab.com. I say 'I' instead of 'we' because Marin is on a well deserved holiday in Norway. I'm using Amazon Web Services (AWS) and Chef which I both like a lot. I've...