Retrieve CI/CD secrets from HashiCorp Vault
In this release, GitLab adds support for lightweight JSON Web Token (JWT) authentication to integrate with your existing HashiCorp Vault. Now, you can seamlessly provide secrets to CI/CD jobs by taking advantage of HashiCorp’s JWT authentication method rather than manually having to provide secrets as a variable in GitLab.
Epic and Issue Health Tracking
Managing multiple epics across multiple groups and projects is difficult. To help users track projects and in-flight work GitLab now enables you to report on and quickly respond to the health of individual issues and epics by showing a red, amber, or green health status on your Epic Tree. Assign an issue a health status of On track (green), Needs attention (amber), or At risk (red) and see an aggregate report of health at the Epic level. Quickly view and analyze where a collection of work is at risk so you can open up the right discussions at the right time and keep work on track!
Import Issues from Jira to GitLab
Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility. GitLab 12.10 includes an MVC to automatically import your Jira issues into GitLab. This is the first of many planned enhancements to make transitioning from Jira to GitLab as frictionless as possible.
To get started, set up the Jira integration on your GitLab project, click the import icon at the top of your project’s Issue List, and select Import From Jira.
Autoscaling GitLab CI jobs on AWS Fargate
GitLab Runner autoscaling responds to CI job demand by provisioning new cloud-hosted virtual machines. However, while this model of automatically spinning virtual machine instances up and down continues to be sufficient for specific use cases, customers also want to take advantage of the capabilities of cloud container orchestration solutions for executing GitLab CI/CD jobs. You can now auto-scale GitLab CI on AWS Fargate with the MVC release of GitLab’s AWS Fargate Driver. With this new autoscaling pattern, GitLab’s AWS Fargate driver automatically runs each build in a separate and isolated container on Amazon’s Elastic Container Service (ECS) using a user-defined container image.
Easy to configure AWS deployment variables
When deploying to AWS, applying the necessary environment variables should be as convenient as possible. You can now select the predefined variables for ‘AWS_ACCESS_KEY_ID’, ‘AWS_SECRET_ACCESS_KEY’ and ‘AWS_DEFAULT_REGION’ from the environment variable key list. You’ll also see the variables you enter validated to ensure they are entered in a valid format.
Link runbooks and assets to a Release
Release and build managers are often in charge of wrangling several activities outside of GitLab in order to effectively deliver a release. GitLab is working to make the Release page a single source of truth for everything regarding your releases. We’ve added the ability to link runbooks to the assets of a Release so you can now track all of these related activities easily and see how far along they are.
Enhanced Secure workflows for use in offline environments
GitLab Secure scanners need internet connectivity to download updates and the latest signatures. GitLab 12.10 makes it substantially easier to use these scanners when running self-managed GitLab instances offline or with limited connectivity. Several adjustments to the underlying scanner job definitions support this workflow.
New documentation for offline environments describes the high-level workflow needed for Secure scanning in an offline environment. We have also added scanner-specific instructions on each scanner’s documentation page.
We will continue to add support for offline Secure scans in future releases, by offering support for additional languages, tools, and use cases.
When your service is down or degraded, your top priority is to fix it. At the same time, you must update customers and business stakeholders about the progress of your fixes. Keeping them in the dark can lead to a flood of emails from unhappy people. Users rely on status pages to confirm if providers know about problems and to learn what to do. When there’s an active incident, knowing what steps are being taken inspires confidence. It helps people to make choices about what they will do in response to the incident.
Today, the new GitLab Status Page is available. Keep users, customers, and stakeholders informed during incidents. Push information from private incidents, like issue descriptions and select comments, from a private incident issue to a public web page. Work directly from the incident issue you are already using for triage and firefighting, instead of bouncing between a lot of different tools.
To begin with, we are targeting one narrow use case. We designed Status Page to publish information from issues in a dedicated incident management project on a private GitLab instance out to public status detail pages. Visit the Status Page Direction to see our plans to add capabilities and support more use cases.
Build, publish, and share Python packages to the GitLab PyPI Repository
Python developers need a mechanism to create, share, and consume packages that contain compiled code and other content in projects that use these packages. PyPI, an open source project maintained by the Python Packaging Authority, is the standard for how to define, create, host, and consume Python packages.
In GitLab 12.10, we are proud to offer PyPI repositories built directly into GitLab! Developers now have an easier way to publish their projects’ Python packages. By integrating with PyPI, GitLab will provide a centralized location to store and view those packages in the same place as their source code and pipelines.
In March, we announced that the GitLab PyPI Repository and support for other package manager formats will be moved to open source. You can follow along as we work to make these features more broadly available in the epic.
Container Network Policies Statistics Reporting
We’re pleased to announce Container Network Policy Statistics Reporting! You can now see data on both total and blocked traffic, allowing you to more easily determine how to configure, tune, and evaluate your Network Policies.
Container Network Policy statistics will appear on a new Threat Monitoring page under the Security & Compliance menu item. By default, this data covers a 30-day period.
Web Application Firewall (WAF) Controls for Logging and Blocking Modes
To help tune rules for false positives or false negatives, you can globally set your WAF to either Logging or Blocking mode on the Operations -> Kubernetes page.