Auto Deploy to ECS
Auto Deploy to ECS
Until now, there hasn’t been a simple way to deploy to Amazon Web Services. As a result, GitLab users had to spend a lot of time figuring out their own configuration.
In GitLab 13.0, Auto DevOps has been extended to support deployment to AWS! GitLab users who are deploying to AWS Elastic Container Service (ECS) can now take advantage of Auto DevOps, even if they are not using Kubernetes. Auto DevOps simplifies and accelerates delivery and cloud deployment with a complete delivery pipeline out of the box. Simply commit code and GitLab does the rest! With the elimination of the complexities, teams can focus on the innovative aspects of software creation!
In order to enable this workflow, users need to define AWS typed environment variables: AWS_ACCESS_KEY_ID, AWS_ACCOUNT_ID and AWS_REGION, and enable Auto DevOps. Then, your ECS deployment will be automatically built for you with a complete, automatic, delivery pipeline.
View Epic hierarchy on a Roadmap
View Epic hierarchy on a Roadmap
When leveraging Multi-Level Epics, it can be difficult to keep track of where each child epic lives on the Roadmap. You can now quickly expand a parent epic on your roadmap to view all its child epics to ensure work is properly organized and your planned timeline is on track!
Versioned Snippets
Versioned Snippets
Snippets are useful for sharing small bits of code and text that may not belong in the main project’s codebase. These items are important to groups and users who rely on them for other tasks, like scripts to help generate diagnostic output or setup supporting services for testing and demo environments. Unfortunately, a lack of version control has made it hard to know if a snippet was the latest version or what changes may have happened and how to reconcile those.
Snippets in GitLab are now version controlled by a Git repository. When editing a Snippet, each change creates a commit. Snippets can also be cloned to make edits locally, and then pushed back to the Snippet repository.
This is the first step in enabling more collaboration on Snippets. In future releases we’ll introduce support for multiple files, continue to expand features and expand permissions.
Dark Theme in the Web IDE
Dark Theme in the Web IDE
For people who spend time working in code editors, the ability to customize the environment to match their preferences is important. Dark themes are some of the most popular for other editors and important for providing a comfortable experience. It’s also clear that GitLab users love their dark themes as a Dark Application theme for all of GitLab is the second most popular request in the GitLab Issue Tracker.
The GitLab Web IDE is now completely themed dark for users who choose the Dark syntax highlighting theme perference. This is an important step in delivering an editing experience users love and a valuable step in understanding how the GitLab UI responds to dark themes. You can read more about the design process here.
Standalone Vulnerability Objects
Standalone Vulnerability Objects
We are excited to announce the first feature release for Vulnerability Management, standalone vulnerability objects. With this release, we’ve implemented a new vulnerability object model, enabling a whole new set of capabilities that span the entire lifecycle of vulnerability management.
One of the biggest benefits is each vulnerability occurrence will now have a unique URL, meaning a vulnerability can be directly linked to, shared, referenced, and tracked as the Single Source of Truth. On this page, you can change the status of a vulnerability to Detected, Confirmed, Dismissed, or Resolved. Another benefit is vulnerability occurrences will persist across scanner runs. Previously, running scans on the same branch would overwrite any previous findings with the new results. Persisting vulnerabilities will improve tracking, visibility, and cut down on duplication of findings between runs. It also enables the future ability to report on group and project vulnerability trends over time across a broad range of variables.
REST API support for DAST scans
REST API support for DAST scans
GitLab 13.0 supports DAST scans of REST APIs. This allows for full DAST security coverage of an application, not just the UI. By supporting use of an OpenAPI specification as a guide for what URLs and REST endpoints need to be scanned, DAST helps secure an application’s entire attack surface and provides more insight into the potential vulnerabilities of any running application.
SAST for .NET Framework
SAST for .NET Framework
We’re introducing initial support for .Net Framework which will allow developers to enable SAST Security Scans on additional types of .NET projects. Like our other SAST jobs, this will use Linux GitLab Runners. We plan to expand support to GitLab Windows Runners in a future release. Since introduction in GitLab 11.0, SAST for .NET only contained support for .NET Core projects.
| Supported Language | Scan tool | Introduced in GitLab Version |
|---|---|---|
| .NET Core | Security Code Scan | 11.0 |
| .Net Framework | Security Code Scan | 13.0 |
Review summary of terraform plan in Merge Requests
terraform plan in Merge RequestsReview summary of terraform plan in Merge Requests
If you use Terraform to define your infrastructure as code, you know the pain of having to pass around the resulting changes from your terraform plan command in slack and MR comments. In GitLab 13.0, you can now see the summary of your terraform plan command in the context where it is most useful, directly in your merge request. This helps you to more quickly verify your infrastructure changes and gives you a place to collaborate with your team members on the intended effects of your infrastructure as code changes.
Users of the Terraform template provided by GitLab will see the terraform plan merge request widget without additional configuration. Users of customized CI/CD templates for Terraform can update their template to use the image and scripts in the official GitLab Terraform template.
GitLab HTTP Terraform state backend
GitLab HTTP Terraform state backend
Users of Terraform know the pain of setting up their state file (a map of your configuration to real-world resources that also keeps track of additional metadata). The process includes starting a new Terraform project and setting up a third party backend to store the state file that is reliable, secure, and outside of your git repo.
Many users wanted a simpler way to set up their state file storage without involving additional services or setups. Starting with GitLab 13.0, GitLab can be used as an HTTP backend for Terraform, eliminating the need to set up state storage separately for every new project.
The GitLab HTTP Terraform state backend allows for a seamless experience with minimal configuration, and the ability to store your state files in a location controlled by the GitLab instance. They can be accessed using Terraform’s HTTP backend, leveraging GitLab for authentication. Users can migrate to the GitLab HTTP Terraform backend easily, while also accessing it from their local terminals.
The GitLab HTTP Terraform state backend supports:
- Multiple named state files per project
- Locking
- Object storage
- Encryption at rest
It is available both for GitLab Self-Managed installations and on GitLab.com.
Exclude large files using Partial Clone
Exclude large files using Partial Clone
Storing large binary files in Git is normally discouraged, because every large file added will be downloaded by everyone who clones or fetches changes thereafter. This is slow, if not a complete obstruction when working from a slow or unreliable internet connection.
In GitLab 13.0, Partial Clone has been enabled for blob size filters, as well as experimentally for other filters. This allows troublesome large files to be excluded from clones and fetches. When Git encounters a missing file, it will be downloaded on demand. When cloning a project, use the --filter=blob:none or --filter=blob:limit=1m to exclude blobs completely or by file size. Note, Partial Clone requires at least Git 2.22.0.
Read more in our recent blog, How Git Partial Clone lets you fetch only the large file you need.
Use variables to power metric dashboards
Use variables to power metric dashboards
In GitLab 13.0, you can create dashboards powered by variables, enabling you to use a single dashboard to monitor multiple services and components, rather than creating hard-coded dashboards for each service you want to monitor. Instead of the time-consuming and repetitive task of recreating similar dashboards multiple times, you can now create a single dashboard and use variables to change the data you view in it.
Reduced memory consumption of GitLab with Puma
Reduced memory consumption of GitLab with Puma
Puma is now the default web application server for both the Omnibus-based and Helm-based installations. Puma reduces the memory footprint of GitLab by about 40% compared to Unicorn, increasing the efficiency of GitLab and potentially saving costs for self-managed instances.
Installations which have customized the number of Unicorn processes, or use a slower NFS drive, may have to adjust the default Puma configuration. See the Important notes on upgrading and GitLab chart improvements for additional details.
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