Skip to content

check_name in Code Quality widget and Code Quality pipeline page is not displayed

Summary

check_name in Code Quality widget and Code Quality pipeline page is not displayed. The feature was originally added in Add check_name to code quality widget (!117402 - merged)

Steps to reproduce

  1. Create a new project.
  2. In the main branch, create .gitlab-ci.yml with the contents:
code_quality:
  script: echo Hi
  artifacts:
    reports:
      codequality: gl-code-quality-report.json

And a gl-code-quality-report.json file with the contents (so it's an "empty" report):

{ }
  1. Create a new branch.
  2. In the branch, modify gl-code-quality-report.json so it looks like this:
[
    {
        "description": "This is a description",
        "check_name": "check_name",
        "fingerprint": "111111111111111111111111111111",
        "severity": "major",
        "location": {
            "path": "this/file/exists.txt",
            "lines": {
                "begin": 1085
            }
        }
    }
]
  1. Create a new MR, with this new branch as the source, and target as the main branch.
  2. Observe the Code Quality Widget. (See screenshot below).
  3. Observe the Pipeline page for the latest pipeline that ran in the MR. (See screenshot below).

What is the current bug behavior?

check_name in Code Quality widget is not displayed

What is the expected correct behavior?

Relevant logs and/or screenshots

Screenshot - MR widget

image

Screenshot - Code Quality Tab in Pipeline page

image

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

# sudo gitlab-rake gitlab:env:info

System information
System:		Ubuntu 24.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	3.2.8
Gem Version:	3.7.1
Bundler Version:2.7.1
Rake Version:	13.0.6
Redis Version:	7.2.10
Sidekiq Version:7.3.9
Go Version:	unknown

GitLab information
Version:	18.4.2-ee
Revision:	527e88bdddb
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	16.10
URL:		https://1.k.git2.cyou
HTTP Clone URL:	https://1.k.git2.cyou/some-group/some-project.git
SSH Clone URL:	git@1.k.git2.cyou:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:

GitLab Shell
Version:	14.45.2
Repository storages:
- default: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version: 	18.4.2
- default Git Version: 	2.50.1

Results of GitLab application Check

Expand for output related to the GitLab application check 

sudo gitlab-rake gitlab:check SANITIZE=true


Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 14.45.2 ? ... OK (14.45.2)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Database config exists? ... yes
Tables are truncated? ... skipped
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ...
5/1 ... yes
5/2 ... yes
12/3 ... yes
12/4 ... yes
21/7 ... yes
21/8 ... yes
27/9 ... yes
29/10 ... yes
29/11 ... yes
36/13 ... yes
1/16 ... yes
41/17 ... yes
41/18 ... yes
47/19 ... yes
49/20 ... yes
52/21 ... yes
54/22 ... yes
1/23 ... yes
61/24 ... yes
63/27 ... yes
61/28 ... yes
1/29 ... yes
72/30 ... yes
95/40 ... yes
95/41 ... yes
98/42 ... yes
100/43 ... yes
100/44 ... yes
104/45 ... yes
107/47 ... yes
109/48 ... yes
111/49 ... yes
113/50 ... yes
113/51 ... yes
118/52 ... yes
118/53 ... yes
1/54 ... yes
113/55 ... yes
125/56 ... yes
125/57 ... yes
130/58 ... yes
1/59 ... yes
Redis version >= 6.2.14? ... yes
Ruby version >= 3.0.6 ? ... yes (3.2.8)
Git user has default SSH configuration? ... yes
Active users: ... 6
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x-9.x or OpenSearch version 1.x-3.x ... skipped (advanced search is disabled)
All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

I'm not familiar with this part of the codebase, but from my investigation it would seem that this might have something to do with the backend not passing check_name to the frontend as we appear to be missing the check_name field in some graphql-related files.

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.