Oct 28, 2022 - JiHu GitLab  

JiHu GitLab 15.5 released with JiHu GitLab Cloud Seed and Autocomplete suggestions

JiHu GitLab 15.5 released with with JiHu GitLab Cloud Seed, Autocomplete suggestions in the Content Editor, Error Tracking Open Beta, Operational Container Scanning and much more!

Today, we are excited to announce the release of JiHu GitLab 15.5 with JiHu 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.

Developer Experience

Making it easier for developers and users

JiHu GitLab and Google Cloud customers can now migrate to the cloud using a single platform. Autocomplete suggestions in the Content Editor provide convenient shortcuts, and errors and other observability data are now easily accessible in the same dashboard with Error Tracking (Beta). JiHu GitLab Runner 15.5, a lightweight, highly-scalable agent, sends CI/CD job results back to a JiHu GitLab instance.

Strengthening Security

Secure by design

The Vulnerability Report is more robust with Operational Container Scanning, and users will now receive an immediate email notification when a two-factor OTP attempt is wrong. Dependency scanning has improved accuracy for Go dependencies for a more accurate software bill of materials (SBOM), while the FIPS-compliant Kubernetes integration ensures compliant software for U.S. Government agencies and vendors.

Enhanced Integrations

Building a better experience for you

The GitHub project importer can now import pull request events and add them to the merge request’s metadata and import GitHub project image resource and other attachments from release notes and comments. Also, now you can configure your JiHu GitLab instance to deliver emails using Microsoft Graph API with OAuth 2.0 client credentials flow.

We thank the wider JiHu GitLab community for the 153 contributions they provided to JiHu GitLab 15.5! At JiHu GitLab, everyone can contribute and we couldn't have done it without you!

Key improvements released in JiHu GitLab 15.5

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:

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.

Autocomplete suggestions in the Content Editor

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.

Rule Mode for Scan Execution Policies

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.

Email notification when two-factor OTP attempt is wrong

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.

Error Tracking Open Beta

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.

Search by environment name in the Environments overview page

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.

Operational container scanning

Other improvements in GitLab 15.5

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:

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 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.

Display all available 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.

Create annotated tags in the Releases page

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.

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-certificates behaviors with gitlab-base. To prevent differential behaviors between Alpine and Debian, and increase consistency across containers, we are going to build the pattern on gitlab-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.

Omnibus improvements

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.

Add labels and dates to a task

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:.

Enforce Developer Certificate of Origin on all contributions

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.

Bulk delete runners in the Admin Area

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.

Display runner owner in Admin Area and group runners page

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.
  • 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.

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.

Important notes on upgrading to GitLab 15.5

  • 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. 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.

Cover image licensed under CC0

Believe it

Get unlimited access to all JiHu GitLab features for 30 days.

Git is a registered trademark of Software Freedom Conservancy, GitLab is a registered trademark of GitLab B.V., we have been authorized to use "JiHu GitLab".
Copyright © 2022 极狐信息技术(湖北)有限公司   |  
鄂ICP备2021008419号-1   |   鄂公网安备42018502006137号

Try JiHu Gitlab risk-free for 30 days.

Have questions? Contact us

Gitlab x icon svg