Today we are releasing versions 10.3.5, 10.2.7, and 10.1.7 for GitLab Community Edition (CE) and Enterprise Editions (EES, EEP).
These versions resolve a regression causing an error when running migrations on MySQL database, which was introduced on the latest security release patch.
If your version of continuous integration is just daily builds, ignoring failed tests, or not testing at all, you're doing it wrong.
Today we are releasing versions 10.3.4, 10.2.6, and 10.1.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).
These versions contain a number of important security fixes, including two that prevent remote code execution, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately.
This security release blog post is the first part of two. The second blog will be posted in approximately 30 days, and it will detail the vulnerability findings.
Please read on for more details regarding this release.
On Tuesday, January 16th, 2018 at 23:59 UTC, we will publish a critical GitLab security update. More details will be forthcoming on our blog, including which versions of GitLab are affected.
We recommend installations running affected versions to upgrade immediately. Please forward this alert to the appropriate people at your organization and have them subscribe to Security Notices.
In GitLab 10.3 we released a new feature: Merge Request Commit Discussions. This is great news for teams who work at the individual commit level, who want to be able to discuss and collaborate on different commits within one merge request. Watch the video below to see this new workflow in action.
In this month’s release of GitLab 10.3 we’ve added new ways to ensure that your code changes are both secure and fast, enhanced your planning and collaboration workflow, and improved your ability to build and ship.
GitLab is a remote-only organization and just like our team, our users are spread across the globe. Conducting remote UX research allows us to quickly connect with GitLab users anywhere in the world. It provides us with the opportunity to gather insight into users’ behaviors, motivations and goals when using GitLab. This helps us to determine what features should be built and how they should behave. But how do we do all this remotely?
GitLab recently switched from PhantomJS to headless Chrome for both our frontend tests and our RSpec feature tests. In this post we will detail the reasons we made this transition, the challenges we faced, and the solutions we developed. We hope this will benefit others making the switch.