GitLab 15.5 released with GitLab Cloud Seed and Autocomplete suggestions
Today, we are excited to announce the release of GitLab 15.5 with GitLab Cloud Seed, Autocomplete suggestions in the Content Editor, Error Tracking Open Beta, Operational Container Scanning and much more!
These are just a few highlights from the 50+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider GitLab community for the 153 contributions they provided to GitLab 15.5! At GitLab, everyone can contribute and we couldn't have done it without you!
To preview what's coming in next month's release, check out our Upcoming Releases page, which includes our 15.6 release kickoff video.
This month's Most Valuable Person (MVP) is Anatoli Babenia
Anatoli made multiple improvements and fixes to the gitlab-docs project during this milestone. The gitlab-docs project is responsible for taking content from many of our projects and publishing it to https://docs.gitlab.com.
Anatoli’s contributions to gitlab-docs during this milestone include improving code quality, adding Ruby code coverage support, and squashing a bug related to launching GitPod.
Thank you Anatoli for all your contributions!
Your nominator had this to say: “It’s been excellent to have some engineering help from the wider community.” Agreed! Thank you Anatoli for all of your contributions.
Deploy apps to Google Cloud with GitLab Cloud Seed
Cloud Seed allows GitLab and Google Cloud customers to migrate to the cloud using a single platform, consolidating their tech stack without slowing down their cloud adoption process.
Cloud Seed is built into the GitLab web UI and leverages CI/CD pipeline capabilities. It is specifically tailored to offer a frictionless developer experience for consuming Google Cloud services, supporting Service Accounts, Cloud Run, and Cloud SQL.
To develop this capability, GitLab worked with Google Cloud to build best-in-class experiences to simplify, automate and thus accelerate cloud resource provisioning, deployment automation and configuration. Google Cloud and GitLab worked together in an open-source model to make Cloud Seed available for paid and free users.
Cloud Seed’s easy-to-use and accessible format drives organic cloud adoption amongst users. Since it is a frictionless, open-source tool, developers and product teams can consume the Google Cloud services complementing its leadership’s cloud adoption efforts leading to an organic company-wide shift. As a result, GitLab is seeing increased bottom-up adoption of cloud services.
Learn more:
- Read the documentation
- Accelerate cloud adoption with Cloud Seed
- Follow development on the Issue Board
Autocomplete suggestions in the Content Editor
GitLab Flavored Markdown provides convenient shortcuts for referencing GitLab-specific items like users, issues, epics, and even emojis in your content. For example, you can type #35266 to link to that issue or :thumb to see a list of thumb emojis. Now when you use the Content Editor, you get access to the same powerful autocomplete suggestions.
Rule Mode for Scan Execution Policies
GitLab now supports editing scan execution policies through the UI in Rule Mode in addition to the Yaml Mode that was available previously. This new visual editor makes it easy to construct a policy, even for non-technical users. Policies can be used to require security scans to run on a schedule or as part of a project pipeline. To get started, have a Project Owner link an associated security policy project on the Security & Compliance > Policies page.
Email notification when two-factor OTP attempt is wrong
On accounts with two-factor authentication (2FA) enabled, bad actors that enter correct usernames and passwords must still enter a correct one-time password (OTP) to access the account. However, users would not know incorrect codes are being entered.
Now users are immediately sent an email when an incorrect OTP is entered, improving security by notifying them that their account might be compromised.
Error Tracking Open Beta
In GitLab 15.5, we are re-enabling GitLab integrated error tracking for GitLab.com in Open Beta. We’ve reworked the architecture so it uses our new Observability backend, leveraging the ClickHouse database as a unified data store. This improvement will enable scaling and a more performant system for the user.
In addition, this sets the groundwork to have errors in the same database as other observability data such as metrics, traces, and logs. We want to allow users to see errors on the same dashboard as other observability data, and enable them to be embedded into issues and incidents.
Search by environment name in the Environments overview page
You can now search the list of environments in the Environments page by name. Previously, there was no search functionality. This sometimes required you to scroll through many pages to find a specific environment and its latest deployment. Now you can easily find an environment by typing in the name into the search bar. Please note you can search for an exact or partial match of the environment name. Wildcards are not yet supported.
Operational container scanning
GitLab now officially supports vulnerability scanning of container images in operational or production Kubernetes environments. You can set up scanning either through the configuration file for your GitLab Agent for Kubernetes or by creating a scan execution policy to require scans to run on a regular cadence.
Results are displayed both on the project’s Vulnerability Report page under the Operational Vulnerabilities tab and also on the Infrastructure > Kubernetes clusters > Agent page under the Security tab. To get started, make sure you have installed the GitLab Agent for Kubernetes and that a scan cadence is defined either in the agent configuration file or in a scan execution policy.
API endpoint to get project transfer locations
We added a new Projects API endpoint that returns a list of groups to which you can transfer the specified project. Previously, you could select which group to transfer a project to from the dropdown list, which didn’t include groups made available through group sharing. Now, the new endpoint ensures that these groups are included too.
Deliver emails using Microsoft Graph API with client credentials flow
If you’ve enabled security defaults in Azure AD, legacy authentication protocols for SMTP are blocked.
You can now configure your GitLab instance to deliver emails using Microsoft Graph API with OAuth 2.0 client credentials flow.
Import more relationships when importing projects from GitHub
Importing all supported relationships during a project import from GitHub can take a long time and is disabled by default. Specifically:
- Image resources and other attachments types.
- Issue events.
- Pull request events.
- All pull request and issue comments (delivered in GitLab 14.2.)
Now you can include these additional relationships in an import if you require them, which slows down the import but includes more information. To import additional relationships, go to the GitHub import page and select appropriate checkboxes under Advanced import settings.
For more information on related features available in GitLab 15.5, see:
- Import pull request and issue events from GitHub.
- Import more relationships when importing projects from GitHub.
Modify user’s commit email through the Users API
Previously, a user’s commit email could be modified only in the UI. Now, administrators can use the Users API to modify the commit email and perform this as a bulk action.
Thank you Neil Drumm for your contribution!
Update group members’ SAML and SCIM extern_uid with API
Previously, if there were changes to group members’ SAML or SCIM identifier (also known as the NameID), the only way to update it was by having users unlink and manually re-link their GitLab and SSO accounts. Now, group owners can update the extern_uid field in GitLab for both SAML and SCIM identities to match the SSO identifier using a new endpoint in the groups API.
Filter issues by health status
Imagine you need a quick view of issues in the current milestone which are at risk. We’ve taken issue health status to the next level, and with this improvement, users can now filter issues that have a specific health status.
Show blocking epics in the roadmap
Since the release of linked epics in 15.0, you could show blocking relationships among epics. With this additional improvement, you can now view that blocking relationship from the roadmaps view.
Unsaved changes to wiki pages are preserved
Anything can happen when you’re writing long-form content in a web browser. An accidental click could close your tab, your browser could crash, or your computer could run out of battery. In many areas of GitLab, content you haven’t posted is saved locally to prevent data loss. You can see this in action when commenting on issues and merge requests. Now you can rest a little easier knowing unsaved changes to wiki pages are preserved in the same way.
Display all available group runners
In the group runners list, you can now view all shared runners, runners from parent groups, and runners you administer. Previously, you could only view the runners you administer. This change provides a more comprehensive overview of group runners.
Expose CI/CD job token scope status in the jobs API endpoint
Since GitLab 14.4 you can limit the access scope of the CI/CD job token for a more secure CI_JOB_TOKEN workflow. If you wanted to determine if the setting was enabled in a project though, the only option was to manually go into the project’s settings. Starting in GitLab 15.5, you can check the response from the /jobs, /deployments and /environments API endpoints and programmatically verify the status of the setting.
Change the internal port for DAST API and API Fuzzing scans
In previous versions of GitLab, DAST API and API Fuzzing scans used a fixed internal port for communications between backend components. In some user configurations this caused a conflict with another configured service. In GitLab 15.5, you can use the DAST_API_API_PORT and FUZZAPI_API_PORT variables to configure the internal port number used by the scanners when it conflicts.
Run security scanning tools in merge request pipelines
GitLab application security scans run in CI/CD pipelines. By default, scan jobs only run in branch pipelines.
Now, you can also run scans in merge request (MR) pipelines by switching to the Latest version of the CI/CD templates instead of the Stable version. This makes it easier to use security scanning if you design your CI/CD pipelines around MR events.
We plan to update the Stable templates with this change in GitLab 16.0.
Note that Latest templates can receive breaking changes in any release. To learn more about Stable and Latest templates, see documentation on CI/CD template versioning.
Use Code Quality with a private, authenticated image registry
The Code Quality scanner downloads and runs container images to scan your code.
Previously, you could pull these images from a custom image registry, but you couldn’t use a private registry that required authentication.
Now, you can provide a registry username and password by setting CI/CD variables when you include the Code Quality CI/CD template.
Create annotated tags in the Releases page
You can now create annotated tags and add them to your releases in the Releases page. You can use annotated tags to provide downstream users and applications with additional information about a release.
Update a release using the Release CLI
In this milestone we added the ability to update a release using the Release CLI. You can use this to automate releases by updating any of the release attributes directly from the .gitlab-ci.yml file, and leveraging the CI/CD pipeline to do so.
More kubectl calls for the agent CI/CD workflow
If you use the GitLab agent for Kubernetes with GitLab CI/CD on GitLab SaaS, previously you couldn’t use kubectl exec, attach, or cp calls. GitLab now supports these calls on top of the SPDY protocol. You can now use kubectl exec, attach, or cp in your CI jobs.
Unfortunately, some cloud providers do not support SPDY. GitLab is working with the Kubernetes community to ship Websockets support in Kubernetes, which will be the solution for many cloud-hosted GitLab instances.
Geo now replicates Incident Metric Images
With this release, Geo supports replication and verification of Incident Metric Images. This protects against loss of this data during failover if Geo is used as part of a disaster recovery strategy.
Omnibus improvements
- GitLab 15.5 includes Mattermost 7.3, with new role-based permissions system for Boards and the ability to create boards independently from channels, multiple Playbooks enhancements including a redesigned left-hand sidebar and run detail page, and much more. This version also includes security updates and upgrade from earlier versions is recommended.
- GitLab 15.5 includes packages for supporting Raspberry Pi OS 11 Bullseye.
- GitLab 15.5 also includes packages for supporting Ubuntu 22.04.
- Some users required the ability for SSL keys to be passwords protected. GitLab 15.5 adds an
nginx['ssl_password_file']configuration to thegitlab.rbfile.
Admin Area setting to prevent users from creating groups
GitLab administrators can now use the Admin Area to disable users’ permission to create top-level groups. Previously, administrators with access to the instance’s file system could change this setting only in the gitlab.rb file.
Import and store attachments when importing from GitHub
You can now import GitHub project image resources and other attachment types from release notes and comments. The attachments are added to GitLab and their links are updated to new GitLab URLs.
Attachments aren’t imported by default because it can be a time intensive operation. To import them, go to the GitHub import page, and select Import Markdown attachments under Advanced import settings when importing using the GitLab UI.
For information on a related feature, see Import more relationships when importing projects from GitHub.
Import pull request and issue events from GitHub
We continue to improve the GitHub project importer by adding more metadata to the migrated projects. With added pull request events history, the following pull request events can be imported from GitHub and become part of a merge request’s metadata:
- Closed or reopened.
- Labeled or unlabeled.
- Review requested or review request removed.
- Assigned or unassigned.
- Edited.
With added issue events history, the following issue events can be imported from GitHub and become part of an issue’s metadata:
- Closed or reopened.
- Labeled or unlabeled.
- Milestone added or removed.
- Cross-referenced.
- Assigned or unassigned.
- Renamed.
Because importing pull request and issue events can take a long time, they aren’t imported by default. To import them, go to the GitHub import page, and select Import issue and pull request events under Advanced import settings when importing using the GitLab UI.
For information on a related feature, see Import more relationships when importing projects from GitHub.
New filters for personal access token API
Prior to this release, API calls to retrieve personal access tokens (PATs) were relatively basic. Now, you can filter results on many properties and link filters together to do complex filtering on parameters such as:
- When a token was last used.
- If a token is revoked.
- A token’s name.
These new API filters for PATs provide users and administrators more useful results from the PAT API.
Thank you Andreas Deicha for your contribution!
Add labels and dates to a task
You can now add dates and labels to a task to better reflect additional context related to the task. You can filter tasks by their labels or sort tasks by due date in a project, group, or dashboard issue list.
Improve DevOps efficiency with the pre-defined DORA comparison report
Following the recent release of the new DORA Insights custom reporting, we have added a pre-defined report to the default insights configuration file. The new report visualizes the performance of the four DORA metrics over the past 180 days, aggregated by month and day.
This report helps you learn the DORA framework, understand how to use the metrics, and see how they perform over time on real data.
Enforce Developer Certificate of Origin on all contributions
The Developer Certificate of Origin (DCO) is a per-commit sign-off made by a contributor stating that they have the right to submit the code to the project. By signing off on a commit, the contributor agrees to the terms published at developercertificate.org.
Now, you can easily enforce this Developer Certificate via a per-project setting to prevent contributors from contributing code that violates your license. When enabled, all new commits must include such a certificate of origin in the form of a line in the commit message Signed-off-by:.
Bulk delete runners in the Admin Area
Bulk editing is a powerful and valuable feature when you need to visualize or manage large data sets. For administrators that manage a fleet of runners, the lack of a bulk delete option is a productivity drain and increases the operational overhead of maintaining runners. Now, in the Admin Area, you can select multiple runners and delete them at the same time. You can also select and delete a full page of runners at once.
Display runner owner in Admin Area and group runners page
For GitLab administrators or group owners, locating a specific runner’s owner can be very time-consuming in environments where many runners are in use at the group or project level. This problem is even more acute and impactful to the customer if the runner in question is not picking up jobs or critical production jobs are running slowly. The Admin Area and group runners page now include an owner column so you can quickly determine the owner of any runner in the environment at a glance.
GitLab Runner 15.5
We’re also releasing GitLab Runner 15.5 today! GitLab Runner is the lightweight, highly-scalable agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
What’s new:
Bug Fixes:
The list of all changes is in the GitLab Runner CHANGELOG.
Dependency scanning improved accuracy for Go dependencies
GitLab Dependency Scanning now uses a new method of detecting Go dependencies that is more accurate than the previous method and allows users to scan the correct version of the dependencies that are actually used by the application.
Static Analysis analyzer updates
GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.5 release milestone. These updates bring additional coverage, bug fixes, and improvements.
- Brakeman analyzer updated to fix a crash in False Positive Detection. See CHANGELOG for details.
- CodeClimate analyzer updated to version 0.87.0. See CHANGELOG for details.
- Kics analyzer updated to add additional rules, fix bugs, and update to kics version 1.6.0. See CHANGELOG for details.
- NodeJSScan analyzer updated to fix an issue with error log processing. See CHANGELOG for details.
- PMD-Apex analyzer updated to version 6.49.0. See CHANGELOG for details.
- Secrets analyzer updated to Gitleaks version 8.12.0. See CHANGELOG for details.
- Security Code Scan analyzer updated to version 5.6.7. See CHANGELOG for details.
- Semgrep analyzer updated to version 0.115.0. See CHANGELOG for details.
- Update GitLab-managed rules to remove false positive results for:
- Java SQL injection
- C# LDAP injection
- C# XPath injection
- Fix a problem where Semgrep-based C# scanning created duplicate findings instead of combining them with Security Code Scan-based scan results.
- Update GitLab-managed rules to remove false positive results for:
- SpotBugs analyzer updated to version 4.7.2. See CHANGELOG for details.
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations.
To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
For previous changes, see last month’s updates.
Access release description from tag in CI/CD pipeline variable
In past releases, there was no easy way to configure a pipeline that refers to a release or to release notes associated with a tag. Now, you can refer to this information using two predefined environment variables: $CI_COMMIT_TAG_MESSAGE and $CI_RELEASE_DESCRIPTION.
Prevent outdated deployment jobs
Previously, some outdated jobs could be manually started or retried even when Skip outdated deployment jobs is enabled. We have updated the logic for this setting to check the deployment status when a job starts. The job does not execute if the deployment job is outdated due to a more recent deployment. This check ensures that outdated deployment jobs are not accidentally started, overwriting more recent code changes in production.
FIPS compliant Kubernetes integration
The U.S. Government requires some GitLab customers to use FIPS (Federal Information Processing Standards) compliant software. You can now use the agent for Kubernetes on FIPS-enabled GitLab installations. This release also adds FIPS-compliant agent images that you can install on your clusters.
Restrict the agent for Kubernetes by environment deployment tiers
Kubernetes administrators can now restrict CI/CD access to specific environment tiers with RBAC, using the agent for Kubernetes.
In past releases, administrators could not restrict access to specific tiers, which added potential security risks to Kubernetes integrations.
Geo now replicates alert metric images
If used as part of a disaster recovery strategy, Geo now supports replication and verification of alert metric images to protect against data loss.
GitLab chart improvements
- In the 15.4 release post, we announced that the GitLab Logger will be used by default for the GitLab Helm Chart in 15.5. This implementation has been delayed to 15.6. For users who have custom log parsers in place, be aware that this will automatically wrap all logs from plaintext to structured JSON.
- Cloud Native GitLab will replace
alpine-certificatesbehaviors withgitlab-base. To prevent differential behaviors between Alpine and Debian, and increase consistency across containers, we are going to build the pattern ongitlab-base. This means operational service containers will share a common root layer, which provides an efficiency boost to Pod instantiation time. The user impact of this, is that we will be changing the image name and tags used. We will maintain a mirrored tag for a brief period. - The GitLab Helm Chart will have a new major version release before the next major GitLab version, separate from the next major version as a whole. We are not sure when this next Helm chart major version will be released, but it can be expected no sooner than 3 milestones, but it may be longer. This major Helm chart release will require downtime, as we incorporate large updates and require manual intervention for upgrade paths.
Improved code search quality for Advanced Search
This release improves code search quality for Advanced Search to bring it closer to the local IDE experience. You can now expect more relevant results for full tokens and some partial tokens as well as better matching for search terms with special characters.
If you created your index in GitLab 15.4 and earlier, you must update code search mappings. You can use zero-downtime reindexing or re-create your Advanced Search index from scratch.
Bug fixes
Some of the notable bug fixes in 15.5 are:
- Progressively load CI/CD variables when there are more than 100 results
- Container Registry only showing 100 tags per image
- NuGet packages with uppercase characters cannot be found
- Group permissions do not allow project moves between namespaces
- Allow custom logo for login page
- Invalid current password error not shown when 2FA setting is on for group
- Fix crash if createAlert dismissed multiple times
- Fix potential for high memory consumption by negative caching
- Fix KAS CI/CD Tunnels to work for projects/groups outside of the group with the agent config
- The Wiki rich text editor preserves new lines between lists and tables
- Wiki pages set as the project landing page display Asciidoc links correctly
- Convert unicode characters included in PlantUML code blocks when switching between Wiki source and rich text editors
- Filter bar missing for developers in audit events
- Import/Export fails to export projects due to errors while exporting merge requests
- GitLab Migration fails systematically with some data not being migrated
- Set BulkImports::Tracker as skipped if entity is failed
- GitHub import: incorrect number of imported issues in import status endpoint
- Missing objects for imported GitHub repository when GitHub API rate limit is reached
- Incorrect “environments” API endpoint path in GitLab UI results in “There was an error fetching the environments information”
- Account owner being removed results in a group with no owner
- HTTP 500 Internal Server Error when listing merge requests with approver and sorting by merged date
- At group level, an empty merge request search result view does not include the buttons, search bar, and tabs
- Finish review fails when Approve merge request is selected on an MR that is already approved
- Merge button is red and the pipeline widget is stuck on “Checking pipeline status”, but the last pipeline is green
- Database timeout in Sidekiq/StoreSecurityReportsWorker
- Allowlist CVE in generalallowlist ignored if no value assigned to key
- Scan Execution Rule mode is not disabled for invalid cron syntax or cron syntax rule mode does not support
- Scan Execution Policy editor UI is incorrectly validating policies before saving
- Policy List Drawer stays open when the security policy project is changed
- Editing DAST Profiles not Disabled for Group Security Policies
- Roadmaps: child epics showing as top level epics
- When moving subepic out of the parent epic, there is no information it was moved in the former parent epic
- Epic errors when loading child issues and epics for signed out users
- Project autocomplete members/commands NoMethodError
- TODOs APIs failing when todo’s target_type is WorkItem
- Filtering roadmap by milestone returns “Something went wrong while fetching epics”
- API Security string values are not escaped by the GraphQlAstPrinter
- API Security GraphQL Schema doesn’t support GraphQL endpoints that have no path
- Reduce API Security XML external entity vulnerability false positives
- Auditors cannot see group CI/CD Runners
- Searching by excluded extension only excludes the first extension
- Prevent users from entering negative number of replicas in Advanced Search settings
- Squash commit message does not honor regex settings
- 500 Error viewing a single large commit
- Codeowners approver list not showing correctly
- Geo:Problems arise if there are multiple parallel Omnibus backup/restore processes
Performance improvements
In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
In GitLab 15.5, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 15.5 are:
- Convert stylesheets/pages/clusters.scss into a page-specific bundle.
- Use the creation timestamp returned by the Container Registry API in cleanup policies.
- Redundant Vulnerabilities::StateTransition records that don’t actually present a state transition
- Loading a specific epic is extremely slow, participants fails
- Migrate API Security analyzer to .NET 6
Usability improvements
In every release, we make great strides in improving the overall effectiveness and usefulness of our product.
We also have a UI Polish Gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.
In GitLab 15.5, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 15.5:
- Improve Package settings loading screen
- Improve modal copy when deleting the last package assets
- Separate issue actions from the activity feed
- Improved layout for comments in the activity feed
- Remove user status and availability from the activity feed
- Update sort order to ‘Last created’ when navigating from admin dashboard using ‘View latest projects’
- Enhance activity menu on Vulnerability Report
- Improve behavior of submit button if initial Personal Access Token submit is unsuccessful
- Make it easier to traverse errors in job logs
Scheduledtag is missing in pipeline details page for scheduled pipelines
Deprecations
New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.
Removals and breaking changes
The complete list of all removed features can be viewed in the GitLab documentation.
Important notes on upgrading to GitLab 15.5
We detected an issue in Geo where runners cloning from secondary sites with proxying fail to find new pipeline refs. This impacts GitLab 14.9, 14.10 and 15.0 with the following configuration: - Unified URL is enabled. - Runners are registered with the secondary sites.
A workaround is to direct GitLab Runners to the primary site. This can be done at the DNS level. Configure the traffic policy to direct all requests from the runner location for the unified URL to the primary site. To be consistent with all other data types, the Container Registry replication now leverages the Geo self-service framework. This is a behind-the-scenes change that will make support and maintenance easier in the future. No action is needed from your part. - GitLab 15.5 automatically migrates the deactivate dormant users period application setting to a minimum of 90 days. This change enforces a minimum inactivity limit of 90 days before users are considered dormant and their accounts are automatically disabled. This minimum ensures a good user experience and compliance with GitLab billing policies. A recent change allowed this feature to set a configurable limit, but did not set the minimum threshold of 90 days.
from GitLab https://ift.tt/7p4v6hI #GitLab #DevSecOps
Comments
Post a Comment