GitLab 12.8 released with Log Explorer, NuGet, and Compliance
GitLab 12.8 is here celebrating "one place!" Get one place for your logs, one place for your NuGet packages, and one place for your compliance activity just like GitLab is one place for your entire DevOps lifecycle.
GitLab 12.8 is here celebrating "one place!" Get one place for your logs, one place for your NuGet packages, and one place for your compliance activity just like GitLab is one place for your entire DevOps lifecycle.
Triage faster with the new Log Explorer
When triaging an incident or validating the status of your service you need to be able to explore Kubernetes Pod Logs from across your entire application. Previously, this was a painful process as you could only see limited logs, couldn't go back in time, and didn't have search. This was complex and time-consuming enough that it could make using Pod Logs impractical for meaningful analysis and instead limit it to simple troubleshooting use cases.
Now, a new Log Explorer lets you interact with all your logs aggregated into one place. Powerful features including filtering, time picker, and full-text search let you quickly get the information you need. This important milestone moves our Logging category from minimal to viable! To get started, install the Elastic stack on your Kubernetes cluster with just one click using the GitLab Managed app, and your logs will be automatically collected and aggregated.
Efficiently store and share C# and .NET resources
Windows has a large, active, and growing development community. While GitLab has already had built-in package management for C/C++, Java, and Node.js, teams writing applications in C# and .NET still needed to use tools external to GitLab in order to store and manage their binaries. This meant they were missing out on the benefits of using a single application across their DevOps lifecycle.
Now, GitLab 12.8 gives teams writing code in C# and .NET a built-in NuGet repository so they have one place to manage and share project binaries both privately and publicly. Developers can now benefit from having their source code, CI/CD pipelines, and the resulting packages all in the same application so they can get work done faster with less effort.
Manage risk with the Compliance Dashboard
Merge requests (MRs) are an elegant and powerful change management tool for keeping a record of changes and approvals. Release teams use MRs to track deployments, and infrastructure teams use MRs to practice GitOps.
Additionally, tracking all MR activity can be critical for organizations that have specific company policies that govern their operations in order to adhere to compliance frameworks, such as SOC 2, ISO 27001, GDPR, SOX, HIPAA, or PCI-DSS, and have specific company policies that govern their operations.
Some examples of governing policies are:
All MRs have a related issue with detailed information about the change(s)
All MRs are reviewed and approved by someone who isn't the author
All MRs pass QA and security testing
Any exceptions to the requirements require separate approval.
Previously, GitLab users lacked the necessary tools to effectively manage their GitLab environment's change management and compliance. Project-level activity was confined to each project, and there was no easy way to view this information in aggregate at the group level. This lack of control and insight created increased potential for risk, reducing users' ability to manage compliance within GitLab.
We have a vision for adding robust compliance management to Gitlab. As a first step towards this vision, we're starting with a Compliance Dashboard which provides a view of the most recent merge requests for each project in a Group. With the capabilities available today, you can manage auditing of your code changes for releases and GitOps from one place. Similarly, this makes it easier for compliance-focused organizations to quickly understand which projects might have greater risk and therefore warrant extra attention. Be on the lookout for more capabilities and improvements in our coming releases.
In a cloud-native world with short-lived services and logs distributed across multiple pods and services, aggregation of logs for observability becomes critical. GitLab 12.8 introduces log aggregation using the Elastic stack.
After attaching a Kubernetes cluster, you can install the Elastic stack, which contains an Elasticsearch instance with Filebeat, a light-weight log shipper. Once enabled, GitLab automatically collects all application logs and surfaces them on the UI.
With this, you will be able to view your aggregated Kubernetes logs across multiple services and infrastructure, go back in time, conduct infinite scroll, and search through your application logs.
This can be useful if you are triaging an application incident or validating the status of your service and need to explore logs from across your application and conduct a full-text search. It also helps you to understand what is affecting your application’s performance and resolve any problems as they arise.
For any organization delivering software, providing teams with an easy and secure way to manage dependencies is critical. Package managers, such as NuGet for C# .NET, provide a standardized way to share and version-control these libraries across projects.
In GitLab 12.8, we are proud to offer NuGet repositories built directly into GitLab. Developers now have an easier way to publish their projects’ NuGet packages. All you have to do is set the NuGet remote to the GitLab Package Registry and start uploading, installing, and deleting packages today.
Compliance-minded organizations need visibility. This becomes more difficult as more groups, projects, and users are added to GitLab, which can make it difficult to manage risk and compliance appropriately.
In GitLab 12.8, we’ve added a group-level dashboard as a first iteration towards bringing compliance insights to group owners. This first iteration focuses on aggregating all of the most recent merge requests (approved and merged) from each project in a group. Group owners can now see all of their merge request activity to be informed and take action if necessary.
We’re pleased to announce initial support for Container Network Security to help prevent lateral security attacks. You can now configure Network Policies in GitLab-managed Kubernetes clusters to limit communication between Kubernetes pods.
Network Policies can control communication between pods and the internet and can prevent unauthorized pods from communicating with other pods in the same Kubernetes cluster. In a multi-application cluster, this feature also enables network segmentation between the different applications.
To support our users who are planning larger collections of related work and manage them across multiple milestones, sprints, and iterations for their teams, we are releasing single-level Epics for our Premium customers!
Spin up an Epic, create and add associated issues, set start and due dates, and organize it quickly with our drag-and-drop Epic Tree.
Clearly defining issue dependencies has just become easier. You can now mark issues as blocking or blocked by other issues. With this new dependency construct, it is now easier than ever to understand issues that may need extra attention (blocked), or to identify issues which will yield high rewards (blocking)! Collaboration efficiency is also increased as inter-team dependencies can now be represented.
The more issues in progress in a given workflow stage, the longer it takes to complete any one given issue. Work In Progress (WIP) limits are commonly used by teams that practice Kanban and is a proven method to improve throughput.
As of 12.8, you can now set WIP limits based on max Issue count per list in an Issue Board. If you exceed your limit, the list background color will change to red.
Blocked issues need attention! Being able to differentiate which issues are blocked while looking at your issue board makes it easier than ever to identify what may be slowing down your team. Remove blockers, and enable your team to run more efficiently than ever!
You can now set the expiration time to stop environments automatically after a certain idle period. This is especially useful for short-lived environments (such as the ones used for Review Apps) to avoid wasting resources. It can be set up through a new entry in .gitlab-ci.yml, for example, auto_stop_in: 1 week, and can be manually overridden from the GitLab UI. Users can also disable auto-stop by pinning their particular environment through the UI and keeping the environment running regardless of the setting.
By preventing a situation where many stale environments are laying around, you don’t waste infrastructure resources by keeping them running. You also gain back development time that would otherwise be spent manually stopping environments.
An instance-level view of the security vulnerabilities is now available. Use this dashboard to see an overview of possible security issues across all of your groups and projects.
In addition to seeing a list of vulnerabilities in your projects and a trend of vulnerabilities over time, you are now able to see your projects across all of your groups categorized by their Security Report letter grade for quick decision making as to which project needs the most attention.
Accessibility of web pages and applications is a growing concern for software developers today. Unfortunately, accessibility testing is often an afterthought occurring late in the software development process. It’s typically a manual and inconsistent process if it’s done at all. Development teams often lack clear requirements from Product Managers or Product Designers outlining accessibility standards to follow when building an application.
Starting in GitLab 12.8, you will be able to automatically scan and get a report of accessibility issues in your Review App. This saves development time by bringing the feedback loop of accessibility issues much closer, so you can have the most impact on making the application accessible for all users. As a first step, you can download a report for every Merge Request.
We see this as a solid foundation to build on in the accessibility testing category. We are looking forward to feedback from customers on our Accessibility Testing category vision.
Managing access to your GitLab.com groups requires visibility into the credentials people are using to take actions within those groups.
In GitLab 12.8, we’ve extended the credentials inventory from self-managed instances to GitLab.com. Now, owners of group-managed accounts can view the SSH credentials and personal access tokens that exist within their groups. This inventory shows the user, the type of credential, and the expiration date so you can make informed decisions about access and rotation.
We’re continuing to add audit events to improve the visibility of activity in your self-managed instances and GitLab.com groups. In this release, we’ve added administrator actions to create, block, or delete users and include username changes in the self-managed instance logs.
These new audit events will help compliance-minded organizations to maintain separation of duties, access management, and nonrepudiation.
GitLab has long supported alternative syntax highlighting themes for use when browsing files in the repository or viewing diffs during the code review process. However, our code editor areas have not supported the use of this preference despite being the most requested feature for the Web IDE.
The Web IDE now supports the Dark syntax highlighting preference in the code area. We’ve started with this theme, as it’s the most widely used one beyond our default, but we’ll continue to expand our support for syntax highlighting preferences in the Web IDE. We’ll also be working on expanding the dark theme to the rest of the Web IDE, including the file tree and sidebars.
Depending on the structure of a Git repository’s packfile on disk, cloning can be CPU- and memory-intensive because Git may need to build and compress a packfile on the fly. Extreme CPU and memory use can occur when a large repository is cloned many times simultaneously, for example during a parallelized CI pipeline. However, if you trigger packfile reuse, instead of constructing the response on the fly, Git streams the packfile directly from disk, eliminating most CPU and memory usage of the clone.
In GitLab 12.8, when repacking repositories, a delta island core is created that contains all the reachable branches and tags so that packfile reuse is triggered when cloning a Git repository. GitLab performs repacks automatically for active repositories, but they can also be triggered manually by clicking Run Housekeeping in the projects General Settings. Note, when using a shallow clone strategy for CI, packfile reuse will not be triggered.
Exploring the source code of a project you’ve just discovered, or a project which you contribute to is now faster. In GitLab 12.8, when browsing between directories, the file list and commit data are updated without reloading the entire page, which eliminates unnecessary page loads.
Merge Requests, particularly the Changes tab, is where source code is reviewed and discussed. Previously, as proposed changes became larger, the diff would load slowly and couldn’t be read until fully loaded.
In GitLab 12.8, the file changes list loads immediately, and the diffs are loaded progressively so that you can begin reading the diff almost immediately rather than waiting for the page to load fully.
In GitLab 12.8, we are including a patched version of Git 2.24 in GitLab Omnibus with improvements to Git packfile reuse.
When a client fetches or clones, it is more efficient for the server to respond by reusing existing packfiles as much as possible. The improvements implement a new smarter algorithm for reusing packfiles that makes a better compromise between the cost to serve a clone or a fetch, and the quality of the resulting packfile.
Thank you Peff and GitHub for sharing this improvement, and Jonathan Tan (Google) for your help reviewing! We hope the patches land in Git 2.26.
Expanding on our new rules syntax, it is now possible to define pipeline rules that are allowed to fail. This gives users more flexibility when setting up their job behaviors and makes it easier to migrate additional projects to our new, more human-readable syntax.
The length of the log in pipeline failure emails has been increased from 10 to 30 rows, making it easier to see more of the trace and more likely that the complete error message is included in the email.
Specifying an empty needs: array can be used to indicate to GitLab that there is no predecessor for that job and that it can always start immediately, regardless of what stage it is in. You can use this to set up more flexible relationships in a DAG pipeline, speeding them up and making them more efficient.
To verify that their NPM package was uploaded or to look up the correct version of a package, users would like to use package metadata. NPM tags can be used to provide an alias instead of version numbers, making it easier to discover packages. For example, a project might choose to have multiple streams of development and use a different tag for each stream, such as stable, beta, dev, or canary.
In GitLab 12.8, we are excited to announce that we now support NPM distribution tags in the GitLab NPM Registry. You can now add, remove, and list tags associated with any package hosted in their registry, making it both faster and easier to find and discover packages.
For organizations building many images across many projects, it is important to remove old, unused images and tags. The container registry garbage collection takes a long time to run and consumes resources inefficiently during the process. This makes it difficult for instances with large registries to run garbage collection and results in an increased cost of storage.
In GitLab 12.8, we are excited to announce a significant improvement in the performance of garbage collection for instances using S3 for storage. These improvements optimize both the mark and sweep phase of the algorithm. While testing on 15 thousand images, the mark phase went from 25 minutes to 90 seconds! The sweep phase went from 20 minutes to 3 seconds! Read more on performance tests and benchmark optimization in the merge request.
You build many Docker images as part of your pipelines, however, many of these images are only needed for a short time. Until now, you’ve had to rely on removing images via the Container Registry API or using the user interface. Both require effort. Wouldn’t it be great to define a policy and have those unwanted tags removed automatically?
In 12.8, we are excited to introduce Docker tag expiration policies for all new projects. This new feature allows you to identify a tag by name, select how many versions of the tag to keep, and define when it should be removed. For example, you can set up a policy that will remove all tag names that match a regex like the Git SHA, always keep at least five images, and remove any image that is older than 30 days.
When users first create a Release entry, a snapshot of the metadata is taken for Evidence in the event of an audit. As of 12.8, we automatically take an additional snapshot of the Release Evidence at the Release end date. By providing a second snapshot, it becomes possible to compare the start state of a Release with its end state. This gives audit teams better visibility into what changed between these two points in time.
As Knative approaches version 1.0, many GitLab users need to build older versions of Knative as many kinks in the Knative upgrade process have not yet been ironed out. A problem arises because new versions of gitlabktl only support a specific version of Knative because of API changes. Because GitLab Serverless is in alpha, we’ve chosen not to support backward compatibility. As we shipped updates, each version of gitlabktl has only supported a specific version of Knative. While this strategy keeps development simple and lets us iterate quickly, it has made it painful to update GitLab, because we were forced to update Knative as well.
The solution to this problem is to use a pinned version of gitlabktl. While this has always been possible, it hasn’t been easy to figure out. We’ve now added a clear set of instructions to our docs to aid in discoverability and execution.
Installing Kubernetes applications using GitLab CI/CD provides a great way to customize applications before installation.
In GitLab 12.8, new templates are available for installing JupyterHub and the Elastic Stack using GitLab CI/CD. Installing applications via GitLab CI/CD will additionally enable version control and access control to the installed charts.
Managing errors in your application is tough enough without needing to also remember to close the GitLab issue after fixing the error. GitLab issues now close automatically after the related Sentry error is resolved. It eliminates the extra manual work and prevents confusion over which issues are still active.
Previously, duplication of dashboards included only default metrics. With this new enhancement in 12.8, custom metrics are now included when cloning a default dashboard with both custom and default metrics.
When troubleshooting an incident, reviewing both logs and metrics is important. When viewing a metric chart, you can now drill down directly into the log explorer while preserving context and without ever leaving the GitLab console.
Searching for a specific environment could get cumbersome when you have many of them. You can now quickly find the environments you want to see in the metrics dashboard with the new search bar in the dropdown menu.
Although this scanner is viable, the feature is currently in alpha as the database only contains Go Module vulnerability definitions from 2019 and later. We appreciate any feedback in this epic around the age and types of Go support desired in addition to any issues you experience. It will help us continue to move this language support out of alpha.
Geo helps distributed teams by replicating data to local Geo nodes, and is also used for disaster recovery. Today, some of GitLab’s features are not yet supported by Geo. We want all upcoming features to ship with Geo support out of the box. To accomplish this, we are moving towards a developer framework, which will make it easier for developers in the GitLab community to contribute new data types that need to be replicated and verified.
This is valuable, because it standardizes the technical processes used in Geo to extend Geo to other parts of GitLab, and it will give the GitLab developer community a solid technical foundation to contribute future features and improvements to Geo. Effectively, future development work will be faster and more efficient.
The Omnibus GitLab package now includes PostgreSQL 11. The PostgreSQL 11 release includes enhancements to partitioning and other performance improvements that we will be building upon in GitLab 13.x to increase its overall speed and responsiveness. PostgreSQL 11 has been fully tested with Omnibus GitLab for new installs and upgrades, including HA configurations. Testing with Geo is in progress.
Upgrades to PostgreSQL 11 are opt-in for GitLab 12.8. For instructions on upgrading, see the upgrade notes. New installs, and automatic upgrades from 9.6, will still default to PostgreSQL 10. PostgreSQL 11 will become opt-out in GitLab 12.10 and the minimum required PostgreSQL version in GitLab 13.0. For more details about GitLab’s PostgreSQL 11 roadmap, see the epic for adding support for PostgreSQL 11.
We’ve introduced new instance-level settings to prevent unwanted changes to merge request approval settings by bringing some of the merge request approval settings from the project settings into the Admin Area. This will give administrators better control of their deployments and allow them to maintain separation of duties when deploying code.
By enabling these settings at the instance level, all projects in a self-managed instance are forced to adopt these settings, and only administrators can change them for an individual project. This new enforcement capability ensures only approved deployments make it into production and brings your GitLab projects into a more compliant state.
Emails sent from your Service Desk on GitLab.com come from the GitLab Support Bot by default. Many times, the originator of the issue does not know that they are emailing GitLab, which makes it confusing.
It’s now possible to configure the name for your Service Desk user! This allows you the opportunity to give your users a recognizable name that matches your brand!
When viewing a design inside the Design tab of an issue, you can drop comment badges on any area of the image and attach a comment. This is great for having point-of-interest discussions. However, as feedback is given and you upload new revisions, sometimes you need to move the badge to a new spot. This release lets you drag badges around. Now you can:
Drag the comment badge around after you drop it.
Move someone else’s badge over to fit yours.
Move the badges to match a new Design after you make a layout revision.
We’ve re-enabled support for Git protocol v2 over HTTP. It was previously announced in GitLab 11.4, but was disabled due to a security issue in Git versions before Git 2.21.
Developers fetch refs many times a day to check if the current branch is behind the remote branch. Git protocol v2 is a major update to Git’s wire protocol which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.
Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. git fetch origin master) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and tens of megabytes of data.
Git protocol v2 is supported from Git 2.18.0 and is opt-in. To enable it, run git config --global protocol.version 2. Git protocol v2 over SSH is not yet enabled. Follow this issue for updates.
Code review is an essential practice of every successful project, and Approval Rules can be used to make sure the right people review each change. When practicing continuous delivery or working on higher risk projects, this is especially important. Previously, adding more restrictive approval requirements to protect the default branch would impose the same requirements on every branch. This forced all merge requests to meet the same approval requirements, whether it be merging a bug fix from master into a release branch, or between two feature branches.
GitLab 12.8 resolves this problem: Approval Rules for Merge Requests set at the project level can be required selectively based on the target branch of the merge request. This allows restrictive approval rules to apply exactly when needed, and even different approval rules to apply to different branches like for stable release branches.
Every commit in a Git repository has an author, but this is not verified by Git and means that it is easy to create commits that appear to be authored by someone else. Commit signing allows you to prove that you are the author of the commit. This is important for sensitive projects and in some commercial environments.
In Git 2.19, OpenGPG signing and verification support was extended to include support for S/MIME using X.509 certificates, because managing these certificates is more friendly for large organizations.
Tabs, in contrast to spaces, are more than a matter of preference for some. For those who use tabs, the correct tab width is no trifling matter. Particularly for C and Go projects, where tabs are most common, it is important that tab width can be configured to match local preferences for the best code review.
GitLab now provides a Tab width user preference, used when viewing code including diffs, CI logs, and rendered code blocks in Markdown.
You can now specify that a job in a project depends on the latest artifact produced by a job in another pipeline, making it much easier to set up cross-project pipelines that have artifact dependencies on each other.
As an example, you might have a pipeline that builds an executable binary. Before this update, you had to rebuild all of the libraries the binary depended on every time you built the binary, even if the library didn’t change. This was a waste of time and computing power, and the workarounds required using a brittle mix of API keys, cURL, and secure variables. Now, by specifying artifacts: true on your needs: job, you can pull the artifact generated by the library pipeline and use it in your final executable pipeline without the need to rebuild.
When running garbage collection to remove old, unused images, users have frequently run into an issue in which the process fails due to corrupted Docker manifests. To resolve this issue, administrators have had to manually remove the corrupted files from object storage, which is slow and risky.
In 12.8, we are excited to announce that any corrupted manifests will now be deleted as part of the garbage collection process. If a bad link file (zero bytes in size or with an invalid checksum) is found during garbage collection, instead of stopping the garbage collector, it will log a warning message and ignore it. Blobs related with invalid link files will be deleted in the sweep stage if those blobs are not associated with another valid link file. This update makes the garbage collection process more reliable and efficient.
We learned from a recent round of user research that users navigate to the Package Registry UI to verify which version of a package they should use or verify that their pipeline built it correctly. However, since we did not display any information in the user interface about how a package was built, users were forced to navigate between several different areas of the application.
In GitLab 12.8, we are excited to announce that packages built via GitLab pipelines will now include pipeline_id, branch, and commit in the Package Registry user interface. This will help users understand how a package was built and troubleshoot much easier when something goes wrong!
The GitLab Container Registry user interface allows you to view, discover and manage your project’s images. The problem is that deleting a tag has been the worst-performing action on GitLab.com, with some requests taking up to 60 seconds to complete. This has resulted in slow page load times and an increased number of support requests.
In GitLab 12.8, we are excited to announce that we have improved the performance of this function by ~70%. This will improve page load times and reliability.
There is a known Docker issue where Ceph-based storage for all requests with absolute URI impacts the Docker garbage collection process. Since DigitalOcean uses Ceph, it prevents users from running garbage collection if they are using DigitalOcean for storage. This results in higher storage costs for those users.
In GitLab 12.8, we resolved this issue by updating the driver for Ceph to support the latest version of the API. This allows any organization using DigitalOcean for storage for their GitLab Container Registry to run garbage collection and lower their cost of storage.
When a CI/CD job deploys to a Kubernetes environment, the job detail page will now display the Kubernetes namespace used for that deployment. You can use the detail page to verify workloads are deployed to the correct destination.
We want to make Review Apps easy to set up even if you already have a functioning .gitlab-ci.yml file. A new Enable Review Apps button has been added to the environments page; if you are using Kubernetes and want to enable Review Apps, this will show you the YAML snippet that needs to be added to your .gitlab-ci.yml.
Until now, users configuring access levels for protected environments needed to update developer and maintainer permissions through the Settings UI instead of the CLI. This wasn’t efficient for users who want to work from the command line and need to maintain the same level of environment access across groups. With this release, maintainers can save time when adding or removing access to protected environments by using the API, rather than having update permissions in the Settings UI.
When it comes to visualizing metrics, users often like to choose different types of visualization for different metrics. To help achieve that, we’ve added column charts as a new visualization option on your monitoring dashboard so you can display your data how you want.
GitLab administrators can now gain insights into the health of their GitLab instances, using a new base project which will be added under the “GitLab Instance Administrators” group. Created for visualizing and configuring key metrics to monitor your GitLab instance.
The y-axis value on the metric chart had previously always started from zero. This made it difficult for users to detect minor changes on the metric charts. Starting with version 12.8, the y-axis values will automatically scale according to the data.
We keep updating our vulnerability database with the latest vulnerabilities. This ensures that GitLab’s scanners are always scanning for the latest vulnerabilities, protecting you and your applications.
In February 2020, we’ve added known vulnerabilities to our database on average within 2.2 days of their announcement. You can see the latest status of our vulnerability updates in the Handbook.
Geo is only available at the Premium and Ultimate tier. Previously, when you tried to enable Geo in the administrator interface using a Starter or Core license, we just told you that the license was invalid - not very helpful! We now provide a clearer message stating which license you are using, which one you need to use Geo, and we also provide a link to manage your license.
GitLab 12.8 includes significant improvements to how projects are imported and exported, resulting in much faster execution times and improved reliability.
Project exports are now four times faster to complete, with 80% reduction in memory footprint. Previously, large projects could fail to export due to exceeding the memory limitations of the export job. With the reduced footprint, these jobs are now much more likely to succeed.
Project imports are approximately 50% faster, due to a significant reduction in database calls. In the future, we plan to reduce the memory required for imports, by switching to newline-delimited JSON.
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 12.8 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.8 are:
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. You can find more details in issue #4915.
GitLab 12.9 will no longer use Alpine for Python Dependency Scanning
We are excited to announce that we are making Debian slim the base image for our Python Dependency Scanning. In issue #13694, we evaluated enhancing our Python support by changing our base image from Alpine Linux, specifically enabling manylinux2010. We decided to switch to Debian slim to make the scanner support more Python projects. You can follow the work in progress in issue #196833.
Because the base image is no longer Alpine Linux, those using Alpine-specific commands, such as apk add <package>, right before the scan (this only applies to users who have disabled Docker-in-Docker) or when building a variant of the official Docker image must make modifications.
GitLab 13.0 renames License Management to License Compliance
GitLab License Management will be renamed to GitLab License Compliance in GitLab 13.0. After review with users and analysts, we determined that this new name better indicates what the feature is for, aligns with existing market terminology, and reduces confusion with GitLab subscription licensing features. You can find the research and work on this issue in the epic Rename License Management to License Compliance. The analyses of your projects done as a part of License Compliance will be called License Scanning.
Starting with GitLab 12.8, those using the License Compliance vendored template may start using License-Scanning.gitlab-ci.yml instead of License-Management.gitlab-ci.yml. With the release of GitLab 13.0, support for License-Management.gitlab-ci.yml will be dropped, and all users on GitLab 13.0 or later using the License Compliance vendored template will have to use License-Scanning.gitlab-ci.yml.
If you are directly referencing the results of the License Scan running as part of License Compliance, you also need to use the new report type artifacts:reports:license_scanning instead of artifacts:reports:license_management. This is optional with the release of GitLab 12.8 through GitLab 12.10, but mandatory with the release of GitLab 13.0. This will not apply to users of versions GitLab 12.7 and earlier.
Offset pagination limit of 50,000 for /projects endpoint
An offset-based pagination limit of 50,000 will be applied on
GitLab.com, and by default on self-managed instances, to the /projects
API endpoint in GitLab 13.0. Integrations which make API calls with
offsets above 50,000 will need to switch to a keyset-based pagination
will offer significantly improved response times and reduced load on the
GitLab server. Self-managed instances will be able to customize the limit
to a desired value.
To provide the optimized performance, keyset-based pagination only offers
ordering based on project id. Use cases which require more flexible
ordering options can continue to use offset-based pagination, provided the
offsets remain below the limit. If use cases require flexible ordering
options with deep offsets, we recommend sorting client-side.
By requiring a minimum version of PostgreSQL 11, we can use its new features without the overhead of maintaining multiple code paths. Going forward, we will maintain a yearly cadence of PostgreSQL upgrades, with the minimum required version of PostgreSQL being no more than two versions behind the latest. We welcome your feedback on the proposed removals in the Move to PostgreSQL 11 and 12 epic.
Undefined will be removed for Severity and Confidence in Secure
Our UX team found that the terminology we used for Severity and Confidence was similar but not the same, which resulted in a lot of confusion. You can read more about that work in the epic Security reports: Remodel severity and confidence. In Secure, we will be deprecating the use of undefined for both Severity and Confidence properties in Security Reports (JSON) and the vulnerabilities API.
If you are searching for or expecting undefined as a filter value in the vulnerability API, you can instead use unknown.