We are accelerating our efforts with Internationalization. A big thank you to members of our community who are already contributing additional languages including Chinese, French, Japanese and Brazillian Portuguese. A huge thanks to Huang Tao for continuously contributing to the cause!
In GitLab 9.4 we have added Internationalization support for the Commits page.
Read through the Internationalization Contribution Guide
Milestones are fundamental to issue tracking. They are often used to designate a sprint (week 35), a release (9.4) or a category (Backlog) of issues and merge requests. Often milestones span multiple projects: you were already able to quickly create milestones in multiple projects at once in GitLab. To make this experience better, we’ve now added the ability to create Group milestones.
Group milestones behave exactly like their counterpart project milestones, but are created in the group and from there available to all projects directly belonging to that project.
To create a group milestone, visit your group and go to Issues and then Milestones.
Read through the documentation on Group Milestones
Additional GitLab Service Metrics
With GitLab 9.4 we have added additional instrumentation to our Ruby on Rails code, providing insight into the HTTP requests, latency, and errors at the Rack middleware layer. We will continue to instrument additional areas of GitLab in subsequent releases.
Read through the documentation on monitoring GitLab
GitLab Geo Improvements
- GitLab Geo now supports PostgreSQL replication slots to prevent secondary Geo nodes from getting out of sync with the primary. See the documentation for more details on how to use it the primary.
- We’ve increased the performance of replicating Git data by adding more concurrent clone operations.
- Geo now ships with an initial version of an event log cursor that allows the secondary track when it needs to update a Git repository. We’ll be deprecating the use of Geo system hooks in the future.
Read through the documentation on GitLab Geo
Object Storage for CI Artifacts
As companies continue to embrace CI/CD across the organization, their artifact storage needs naturally increase as well. With GitLab 9.4 you can move existing CI artifacts to Amazon S3, in order to free local space and enable artifacts to be saved cost effectively, reliably, and with nearly infinite scalability. For now this operation has to be run every time you want to move your local artifacts to S3, but in a future iteration it will be automatically done so all the new artifacts will be saved on object storage as soon as they’re created, without the need of a manual migration.
Read through the documentation on CI Artifacts
Extended Docker Configuration for CI/CD
In GitLab 9.4 we introduce new advanced configuration options for
.gitlab-ci.yml that allow you more flexibility when defining Docker images that you want to use for your pipelines. These improvements require also GitLab Runner 9.4 or above.
You can now specify a custom
entrypoint for your Docker image, in order to override the default one: here is an example to set the entrypoint to
/bin/sh, making the image suitable for GitLab CI jobs without further modifications:
You can also specify aliases for services to run multiple concurrent instances of the same Docker image, and specify commands directly in the configuration file.
- name: super/sql:latest
command: ["/usr/bin/super-sql", "run"]
- name: super/sql:latest
Read through the documentation on extended Docker configuration options
Security - Add LDAP SSL Certificate Verification
We added support for certificate verification for LDAP over SSL. This option will be disabled by default for backwards-compatibility until GitLab 9.5. Additionally, to aid in configuring a secure connection, you can now specify a CA certificate file and SSL version. Encryption method names
tls have been deprecated in favor or
Read through the documentation on LDAP
GitLab Mattermost 4.0
GitLab 9.4 includes Mattermost 4.0, an open source Slack-alternative, with a new look, new mobile apps, new API and Italian language support.
This version includes security updates and upgrading is recommended.
Read through the documentation on GitLab Mattermost 4.0
When using a container registry that is external to the Omnibus GitLab package, there is additional configuration required starting with the 9.4.0 release.
Previously, only the path to the registry key used for communication between GitLab and the registry (
gitlab_rails['registry_key_path']) was necessary. Now along with the path, it is also required to specify the content of the key by setting
registry['internal_key'] inside of
/etc/gitlab/gitlab.rb. Documentation for utilizing an external registry will be available soon.
- NGINX has been updated to the next stable version, 1.12.1
- openSUSE 42.2 is now officially supported
Read through the documentation on Omnibus GitLab
Unified Slack Interface
With this release, we are unifying the issue information shown in Slack in response to a link being pasted, a Slack slash command being executed, or a Slack notification. This provides a coherent experience regardless of how an issue is referenced in Slack.
PostgreSQL High Availability (Beta)
GitLab 9.4 arrives in Beta for deploying the bundled PostgreSQL server in a highly available manner, with a simple manual action to recover in the event a node goes down. This allows for a more robust deployment of GitLab, reducing the duration of an outage and potential for data loss. We are working to automate the failover process in a subsequent release.
Read through the documentation on PostgreSQL HA with Omnibus GitLab
Mini-Graph for Multi-Project Pipelines
We recently introduced Multi-Project Pipeline Graphs to easily follow dependencies between related projects. With GitLab 9.4 we extend this also to mini-graphs in the Merge Request widget, where you can now see pipelines for downstream projects with their current status.
Read through the documentation on Mini-Graph for Multi-Project Pipelines
Customizable Path for CI/CD Configuration
GitLab defines CI/CD configuration in a YAML file named
.gitlab-ci.yml that is located in the root of the repository. There are cases where you need to specify a different location for the definition of your pipelines, for example when you mirror a SVN repository and cannot have files in the root of the project.
Starting with GitLab 9.4, you can now specify in Settings > Pipelines a custom path that will be used to read CI/CD configuration instead of the default
.gitlab-ci.yml. A variable named
$CI_CONFIG_PATH is available to jobs in order to access the current config location.
Read through the documentation on GitLab CI/CD
New Cache Policy for CI/CD Configuration
The default behaviour of a caching job is to download the files at the start of execution, and to re-upload them at the end. This allows any changes made by the job to be persisted for future runs, and is known as the pull-push cache policy.
The default behaviour of a caching step is to restore and archive dependencies of your jobs, allowing speed-up of subsequent runs. If any change is made to the cached content, it is pushed to the cache server by default, and this behavior is known as the pull-push cache policy.
If you’re not interested in updating the cached files for a specifig job, you can skip the upload step by setting
policy: pull in the job specification. Alternatively, if you have a job that unconditionally recreates the cache without reference to its previous contents, you can use
policy: push to save a lot of unnecessary load on the cache server. This feature requires GitLab Runner 9.4 or above.
Read through the documentation on GitLab CI/CD
Improved Prometheus Monitoring of Kubernetes Deployments
Since the release of GitLab 9.0, the Prometheus server bundled with Omnibus GitLab has supported monitoring Kubernetes nodes for CPU and Memory metrics. With the release of 9.4, the Prometheus server will also automatically monitor any specifically annotated Pod metrics as well.
Read through the documentation on monitoring Kubernetes
Upcoming Omnibus Package Signing
Starting with our 9.5 release on August 22nd, we will be signing all new packages going forward. Along with the 9.5.0 package, we will also be providing signed versions of the latest 9.4 and 9.3 releases.
Package signing provides additional confidence that the
.rpm files used to install GitLab have not been surreptitiously modified.
GitLab Runner 9.4
We’re also releasing GitLab Runner 9.4 today!
Most interesting changes:
List of all changes can be found in GitLab Runner’s CHANGELOG.
Read through the documentation on GitLab Runner
We are continuing to make great strides improving the performance of GitLab in every release. We’re committed to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
In GitLab 9.4 we are shipping performance improvements for issues, projects, milestones, and a lot more!
For a list of implementations, please check the merge requests for GitLab Community Edition and GitLab Enterprise Edition.