In GitLab 12.10, GitLab introduced functionality for GitLab Runner to fetch and inject secrets into CI jobs. GitLab is now expanding the JWT Vault Authentication method by building a new
secrets syntax in the
.gitlab-ci.yml file. This makes it easier for you to configure and use HashiCorp Vault with GitLab.
GitLab’s Kubernetes integration has long enabled deployment to Kubernetes clusters without manual setup. Many users have enjoyed the ease-of-use, while others have run into some challenges. The current integration requires your cluster to be open to the Internet for GitLab to access it. For many organizations, this isn’t possible, because they must lock down their cluster access for security, compliance, or regulatory purposes. To work around these restrictions, users needed to create custom tooling on top of GitLab, or they couldn’t use the feature.
Today, we’re announcing the GitLab Kubernetes Agent: a new way to deploy to Kubernetes clusters. The Agent runs inside of your cluster, so you don’t need to open it to the internet. The Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to the cluster. No matter what method of GitOps you use, GitLab has you covered.
Note this is the first release of the Agent. Currently, the GitLab Kubernetes Agent has a configuration-driven setup, and enables deployment management by code. Some existing Kubernetes integration features, such as Deploy Boards and GitLab Managed Apps, are not yet supported. Our vision is to eventually implement these capabilities, and provide new security- and compliance-focused integrations with the Agent.
If your team needs to maintain separation of duties between team members who own development, and team members who own deployments, the permissions paradigm in GitLab has made this challenging. In GitLab 13.4, you can give non-code contributors permission to approve merge requests for deployment, and actually deploy code, without also granting them maintainer access.
Today, the Vulnerability Management experience at the Instance level is limited in both functionality and flexibility. The current experience is a single page that combines vulnerability details, metrics visualizations, and configuration. There’s not much room to expand these functions or leverage other security features.
We’ve made a foundational change to security visibility and management in GitLab. The Instance Security Dashboard has been transformed into a Security Center. The biggest change is introducing a new menu structure. Rather than a single page, you can now find a Security Dashboard, Vulnerability Report, and Settings area. While the functionality hasn’t changed, breaking things apart enables future enhancements that would have been difficult otherwise. This also creates a top-level framework for including other security-related functionality in the future.
The dedicated Vulnerability Report now has more room to display important details and inherits those currently found on the Project vulnerability list. Separating the vulnerability metrics widgets into their own area creates a true Security Dashboard. This is now a dedicated canvas for future visualizations—-not just for managing vulnerabilities but for any of our security-related metrics. Finally, splitting Settings out into its own area creates a new shared space for instance-level security configuration beyond Vulnerability Management.
In GitLab 11.4 Feature Flags were introduced. In 12.2 we introduced percent rollout and user ID feature flag strategies. In 13.1 we introduced feature flag user lists and support for multiple feature flag strategies per environment.
Earlier this year, GitLab committed to moving 18 features to our open source core product. With this release of GitLab we’ve finished moving Feature Flags to Starter, and we are continuing to migrate our Feature Flag service to Core in GitLab 13.5. We’re excited about bringing these features to more users and seeing what use cases and workflows you use them for.
When navigating through GitLab, sometimes you just want to go to a specific project and not a search result page.
Using the Global search bar, you can now quickly jump to recent issues, groups,
projects, settings, and help topics. You can even use the
/ keyboard shortcut
to move the cursor to the search bar, to navigate GitLab even more efficiently!
When Reviewing a Merge Request it is difficult to determine if the modified code is covered by a unit test or not. Reviewers may instead rely on the overall coverage value and require an increase in the value before they approve the Merge Request. This can lead to a scattershot approach of test writing by developers that may not actually improve code quality or coverage.
Now a developer will see a visual representation of code coverage in the Merge Request diff when doing a review. This visual indicator makes it easy to see if the modified code is covered by a unit test or not, helping speed up code reviews and the time for a feature to be merged and deployed.
Thank you to Fabio Huser and Siemens for the contribution!
Since GitLab 12.5, you could only see 7 environments across 3 projects with the Environment Dashboard. We’ve improved the Environment Dashboard in GitLab 13.4 by paginating the dashboard to help you support and manage your environments at scale. You can now see more environments across many projects.
We’ve recently received maintainer rights to the GitLab Terraform provider and plan to enhance it in upcoming releases. In the past month we’ve merged 21 pull requests and closed 31 issues, including some long outstanding bugs and missing features, like supporting instance clusters. You can read more about the GitLab Terraform provider in the Terraform documentation.
API Fuzz Testing is a great way to find bugs and vulnerabilities in your web apps and APIs that other scanners and testing techniques miss.
GitLab’s API fuzz testing lets you provide an OpenAPI v2 specification or a HAR file of your application, and then automatically generates random inputs designed to exercise edge cases and find bugs. Results are then immediately shown as part of the pipeline.
This is our first release of API fuzz testing and we’d love to hear from you and know what you think. We have a lot more in store for fuzz testing that we’re excited to build on top of this release!
Previously, creating a chart in your GitLab metrics dashboard was challenging. After you defined a chart in the dashboard YAML file, you committed the changes to
master without knowing the newly-created chart was what you wanted. Since GitLab 13.3, you can preview a panel’s YAML as the chart is created, getting you early feedback before committing the changes to your dashboard’s YAML file.
When you or your team manages multiple GitLab projects, you should be able to easily see a single data point showing how code coverage is trending over time across all projects. Previously, visualizing this trend involved tedious, manual, work to download the coverage data from each project and insert it into a spreadsheet.
Now, as team lead, you can quickly and easily gather all the code coverage data available in each of your group’s projects or a selection of projects as a
.csv file. This is an MVC feature that will be followed by the ability to graph the average coverage over time.
This release introduces support for multiple new languages to coverage-guided fuzz testing.
You can now leverage all the power of fuzz testing for your apps written in Java, Rust, and Swift to find bugs and security vulnerabilities that other processes miss!
The environments page shows the general status of your environments. In this release, we improved the environment page by adding alerts. Seeing triggered alerts alongside the status of your environments enables you to take immediate action to remedy situations.
When using parent/child pipelines, it is now possible for child pipelines to trigger their own child pipelines. This added depth can be useful when you want the flexibility to generate a variable number of child pipelines.
Before, with a parent/child configuration, every child pipeline needed a trigger job manually defined in the parent. Now you can generate child pipelines that dynamically trigger any number of new child pipelines. If you have a monorepo, for example, you can dynamically generate a first child pipeline that itself generates a variable number of new child pipelines, based on the changes in a branch.
Navigating between parent and child pipelines was a bit cumbersome, requiring multiple clicks. It also wasn’t easy to tell which job triggered which child pipeline. It’s now easier and faster to see how parent pipelines connect with their children.
If you used matrix jobs, you probably noticed it was difficult to determine which matrix variables were used for each job, because the job names were formatted like
matrix 1/4. In 13.4, you will now see the relevant variable values that were used in that job, instead of seeing a generic job name. For example, if you are building a debug target for x86 architecture, the job will now be named
matrix: debug x86.