Skip to content

Invalid artifacts:reports:codequality:path specification causes job to show as running but runner logs error and job is not processed

Summary

A code quality report job should be configured as per the following example:

codequality-scan:
  scripts
    - echo "Running"
  artifacts:
    reports:
      codequality: gl-code-quality-report.json

If however a job is configured incorrectly with a path: attribute as shown below no pipeline syntax error is displayed in the UI, and the job is picked up by a runner:

codequality:
  scripts
    - echo "Running"
  artifacts:
    reports:
      codequality: 
        path: gl-code-quality-report.json

The runner then logs the following error, and no job processing takes place, leaving the job showing as running in the UI with an empty log:

WARNING: Checking for jobs... failed                correlation_id=01K6KPBVZKRN52ESQ892ZD786X runner=1-Op0trVK status=Error decoding json payload json: cannot unmarshal object into Go struct field Artifact.artifacts.paths of type common.ArtifactPaths

image.png

Reproducible in GitLab version 18.4.1.

Reported in support ticket (ZD internal link).

Steps to reproduce

Configure a job with an invalid artifacts:reports:codequality:path attribute and run the job.

Example Project

What is the current bug behavior?

Job config passes the syntax check and is passed to the runner, where it then gets stuck in "Running" state.

What is the expected correct behavior?

Pipeline YAML syntax check should detect error and prevent job from being scheduled.

Same applies to all artifact report types.

The Runner should also perhaps deal with this scenario more gracefully and report back to GitLab that the job has failed rather than leaving it hanging.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

   (For installations with omnibus-gitlab package run and paste the output of: \\\\\\\`sudo gitlab-rake gitlab:env:info\\\\\\\`)  (For installations from source run and paste the output of: \\\\\\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\\\\\`)

Results of GitLab application Check

Expand for output related to the GitLab application check 

  (For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:check SANITIZE=true\\\`)  (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\\\`)  (we will only investigate if the tests are passing)

Possible fixes

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.

Edited by Justin Farmiloe