GitLab CEO Sid Sijbrandij occasionally sits down for a 'pick your brain' meeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab.
It was great to find the time for us to pick Sid’s brain and learn from the history and the organizational challenges that GitLab had overcome so that we may reference them for building a better organization. There were some cultural elements, tactical organizational elements and software development process-related elements that were valuable pointers.
Tasktop, the value stream integration tool for enterprise development teams, has launched their GitLab Issues Connector. Now you can automatically flow GitLab issues bi-directionally into tools such as JIRA, CA Agile Central (formerly Rally), HPE ALM, and VersionOne, facilitating effective DevOps at scale.
In 9.4 we took a big step toward improving our navigation here at GitLab. After several rounds of research and testing, we released our redesigned navigation under a feature flag. We chose this method so that we could continue implementing improvements discovered in our original research while gathering real-world feedback from our users.
Developers rely on multiple platforms to manage repositories, depending on client and project needs. They might contribute to a community project on GitHub, while working on one client's on premises GitLab instance and another client's project in Mercurial on Bitbucket. Confusion can arise when you switch between platforms. In this post, we have a handy reference guide to explain some potentially confusing terms, especially if you're new to GitLab.
Fast-growing companies sometimes need leadership in new initiatives before there's time to hire a team member dedicated to them. This is how we tackled this challenge.
Today we're celebrating GitLab Fan and the great work they do to evangelize GitLab 🎉 Read on to learn more about the mysterious figure behind the Fan, and take a look around our site and see if you can spot any of their illustrations. Also, don't forget to visit us on Twitter to take part in our giveaway – you could get your hands on some awesome, custom GitLab Fan swag.
Today we are releasing versions 9.5.4, 9.4.6, and 9.3.11 for GitLab Community Edition (CE) and Enterprise Edition (EE).
These versions contain several security fixes, including fixes for several persistent Cross-Site Scripting (XSS) vulnerabilities, a fix for a hard to exploit race condition in project uploads, a fix for a CSRF token leakage vulnerability, a fix for a bug that could allow deleted repositories to be left on disk and copied by a user that knew their full path, some important Mattermost updates, a fix for a critical vulnerability in the Nokogiri library, a fix for a vulnerability that could allow the disclosure of private SSL certificates in Pages sites, and several more. We recommend that all GitLab installations be upgraded to one of these versions.
Please read on for more details.
At fleetster, we have our own instance of GitLab and we rely a lot on GitLab CI. How could it be otherwise? We are a small team, with a lot of different projects (only in last month, we had more than 13,000 commits over 25 different projects, and we are only 10 people – with myself working part time). Automating as many development steps as possible (from build to QA to deploy) is helping us a lot, but sometimes we write some code and then forget about it. This is a disaster! We have some bug fix or some new feature ready, but it is forgotten in some branch somewhere.
This month, when we release GitLab 10.0, deprecated runners will not be able to communicate with the system anymore, since they rely on an old version of the API that will be removed. All runners with version 9.0 or newer will continue to work as usual without any modification. We encourage all of our users who still have old runners deployed to upgrade them to the latest version as soon as possible to avoid any downtime.