A common challenge many development leaders face is having visibility into the overall application security and compliance status of their projects. This month's GitLab release helps you more efficiently monitor the application security and release compliance of your projects.
With GitLab 12.6, a new Project Security Status panel shows how projects are ranked according to their security profile. This makes it easier for development leaders to quickly understand which projects may have greater risk and therefore might warrant additional attention to address specific issues.
Almost every enterprise development team is expected to document and demonstrate that each release complies with their organization’s policies, procedures, and controls. Often it means they have a manual processes to save the documentation so that future audits can review the compliance evidence. GitLab 12.6 makes audits and compliance much easier, with a release evidence file in the form of a JSON object that includes links to the milestones and issues that were included in the release, which can help to streamline future audits.
Efficiently Manage and Share C/C++ Resources
Many teams are actively developing new high performance applications in C and C++ and they need the ability to easily store and manage the compiled files and binaries from their projects. GitLab 12.6 now helps teams writing code in C and C++ to manage and share both privately and publicly the binaries from their projects with the popular Conan repository built into GitLab. They can now benefit from having source code, automated GitLab CI pipelines and the resulting packages in the same application which will help improve their overall efficiency and velocity.
And Much More
These are just a few of the highlights in 12.6. Check out the other great updates, such as dependency scanning for Java Gradle projects and support for squash-and-merge within Merge Trains.
Also, registration is open for the next GitLab Commit User Conference in San Francisco, January 14.
Key improvements released in GitLab 12.6
Quickly understand your at risk projects with Project Security Grades
We’re excited to announce a new “security grades” feature in Group
Security Dashboards. In addition to the existing vulnerabilities list
and history, this new panel on the Group Security Dashboard lets you
know which projects are most affected/at risk so you can go right to the
projects that need the most immediate attention.
The severity of any detected vulnerabilities on a project is used to
create a simple A through F letter grade. Projects are grouped by
grade, so you can easily see which have no unresolved vulnerabilities
(grade A) through to those with at least 1 critical (grade F).
Deprecations
Kubernetes 1.11 no longer supported
When deploying GitLab in Kubernetes, the minimum supported version of
Kubernetes is now 1.12. Kubernetes 1.11 is no longer maintained
upstream,
and has recently been dropped by popular container management services
such as GKE and EKS. GitLab uses Kubernetes 1.13 by default.
Planned removal date:
Dec 22, 2019
Deprecated variables and argument for manual configurations of .gitlab-ci.yml when using Secure features
As previously announced in Release Post
12.0,
if you have manually configured .gitlab-ci.yml:
- The command line argument
--auth-first-page was removed in issue 7182 and is no longer supported and you need to remove it.
- The
DEP_SCAN_DISABLE_REMOTE_CHECKS flag variable for Dependency Scanning was removed in issue 9953 and is no longer supported and you need to remove it.
- The
sast_container value in the GITLAB_FEATURES pre-defined environment variable was removed in issue 8217 and is no longer supported and you need to change it to container_scanning instead.
- You also need to verify that you are using the new report syntax, since all Security scanning features are dependent on the reports being available in the expected location. If you do not update to the new report syntax, they will stop working.
If you use the vendored templates instead of manually defining the jobs, you don’t need to do anything.
Planned removal date:
Dec. 22, 2019
All find-sec-bugs analyzers have been replaced by spotbugs
We’ve deprecated our four find-sec-bugs analyzers:
find-sec-bugs,
find-sec-bugs-groovy,
find-sec-bugs-sbt,
find-sec-bugs-gradle.
You should be using our
spotbugs
analyzer in place of these.
Planned removal date:
Dec. 22, 2019
Elasticsearch 5.6 no longer supported
As we continue to improve and enhance our integration with Elasticsearch, support for
Elasticsearch 5.6.x will end with the release of GitLab 12.7. Elasticsearch 5.6 reached its
end of life with the release of Elasticsearch 7.x. Updated
version requirements
for GitLab 12.7 will include support for only Elasticsearch 6.x.
At this time there is no timeline for support of Elasticsearch 7.x with GitLab; you can follow
this issue for updates. GitLab recommends
self-managed customers upgrade to ElasticSearch 6.x.
Planned removal date:
January 22, 2020
Backported os.Expand
In GitLab Runner 13.0 we will remove the backported os.Expand() from Go
v1.10.8. This backport was needed to include a change in behavior
introduced in Go v1.11. Additional details can be found in issue #4915.
Planned removal date:
May 22, 2020
Manual parsing of DockerService
In GitLab Runner 13.0 we will revert to using the default TOML parser.
Additional details can be found in issue #4922.
Planned removal date:
May 22, 2020
Windows Batch cmd for the shell executor
In GitLab 11.11, we deprecated the use of Windows Batch executor for the
GitLab Runner. Support for Windows Batch will be removed in GitLab 13.0.
Additional details can be found in issue #6099
Planned removal date:
May 22, 2020
Deprecate Ruby string interpolation on Prometheus queries
We plan to remove the Ruby string interpolation (curly braces with a
leading percent) in the next major version (GitLab 13.0) and replace it
with liquid template
support. If you are
using the following format 'string_%{variable}_string' on your
Prometheus queries to pass parameters, you’ll need to replace it with
'string_{{variable}}_string'.
Planned removal date:
May 22, 2020
Gitlab 13.0 will drop support for InfluxDB self monitoring metrics
We plan to remove the GitLab self monitoring metrics collected by
InfluxDB in the next major version (GitLab 13.0).
Prometheus
is our official self monitoring tool for GitLab. It is installed by
default on every GitLab instance and is collecting the same metrics as
InfluxDB.
Planned removal date:
May 22, 2020
Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0
To take advantage of improved performance and functionality in PostgreSQL 11 such as
partitioning, we
plan to require PostgreSQL versions 11 and
12 in GitLab 13.x. To accomplish this, we will
be introducing support for PostgreSQL 11 in an upcoming release of GitLab 12.x while maintaining support for 9.6 and 10.x.
With the arrival of GitLab 13.0, PostgreSQL 11 will be required.
By minimally requiring PostgreSQL 11, we are able to leverage the new features introduced, without
the overhead of maintaining multiple code paths. Going forward, we will be maintaining a yearly
cadence of PostgreSQL upgrades, with support for the second and third most recent versions as soon as
we are able to add them. We welcome your feedback on the proposed removals. Please comment in the
Move to PG 11 and 12 epic.
Planned removal date:
May 22, 2020
Move Geo settings to Admin Area > Geo > Settings
Geo settings have
moved to Admin Area
> Geo > Settings. The old location (Admin Area > Settings > Geo)
will remain available with automatic redirection until GitLab 13.0.
Planned removal date:
May 22, 2020
Important notes on upgrading to GitLab 12.6
As part of our architecture updates for GitLab pages, Pages will be using an
API instead of using disk-database access. This has already been done on
GitLab.com.
To help with the larger migrations, we have introduced background migrations
(Sidekiq jobs that will run asynchronously) for this release. For
GitLab.com, these migrations took around 36 hours to complete, and no side
effects were expected nor introduced.
To find the approximate time it will take to complete these migrations on
your instance, run the following command from a Rails console:
(Project.count.to_f / 300_000).ceil. To check the status of the background
migrations, run: Sidekiq::Queue.new
('background_migration').size.
For more information see the issue for Pages virtual host configuration
API.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback