module id missing in npm build info

[debben]

Describe the bug

Beginning today right after the 2.9.0 release of jfrog-azure-devops-extension a number of my pipelines began failing when using the JFrogPublishBuildInfo task. The output from the CLI was

16:22:54 [Info] Deploying build info...
16:22:54 [Error] server response: 400 
{
  "errors": [
    {
      "status": 400,
      "message": "Module id name cannot be null!"
    }
  ]
}

Current behavior

When I looked at the diff, I noticed defaultJfrogCliVersion changed from 2.44.1 to 2.52.1. Locally I experimented with both versions of the CLI and found that the former version was producing the appropriate-looking build info:

{
  "modules": [
    {
      "type": "npm",
      "id": "modulename",
      "dependencies": [
      ]
    }
  ]
}

But when I repeated the same steps cli 2.52.1, the build info lacked the "id" attribute.

Reproduction steps

Clone or produce an example node app (any package.json should do).

run jf npm ci --build-name="YourBuildName" --build-number="YourBuildNumber" --threads=1

This will produce a temp#### build info file under %HOME%\AppData\Local\Temp\jfrog\builds<hash of your build name+number>. In 2.52.1 and 2.52.2 of the CLI, I experienced the behavior of missing "id" attribute from modules build info.

Expected behavior

I expect the build info produced to have the "id" attribute for npm modules.

As a breadcrumb for other Azure DevOps users out there, I found I could pin the CLI version back to 2.44.1 by setting JFROG_CLI_PIPELINE_REQUESTED_VERSION_AZURE as a pipeline variable.

JFrog CLI version

2.52.1

Operating system type and version

Windows Server

JFrog Artifactory version

7.75.4

JFrog Xray version

No response

[sstephant]

Someone in my team has a simmilar problem with a python build

15:06:03  [Info] Deploying build info...
15:06:03  [Error] server response: 400 Bad Request
15:06:03  {
15:06:03    "errors": [
15:06:03      {
15:06:03        "status": 400,
15:06:03        "message": "Dependency id name cannot be null!"
15:06:03      }
15:06:03    ]
15:06:03  }

The JFrog CLI version is 2..52.9

[Quixotical]

our team is also having this issue

19:02:48 [Info] Deploying build info...
19:02:49 [Error] server response: 400 
{
  "errors": [
    {
      "status": 400,
      "message": "Dependency id name cannot be null!"
    }
  ]
}
script returned exit code 1

@sstephant was your team able to find a solution to this?

We are using version 2.52.10 in a linux environment

What's annoying is that I have several deployments and the first one works without a problem, then the second one fails. I can change the order of deployments and in each case the first one always works and the next fails. Retrying/waiting does nothing to alleviate the problem

EDIT I was able to resolve this problem by isolating my jfrog cli commands for different images to different containers. It seems the issue was that there is some sort of destructive action when you run jf rt commands and so the first publish would work, then the second would fail with this error, putting each in their own container fixed the problem.

[kunkka-m]

Got the same issue after upgrade jfrog-cli-v2-jf to 2.59.0. Only some jobs had this error, while most jobs are normal

• set +x [Error] server response: 400 { "errors": [ { "status": 400, "message": "Module id name cannot be null!" } ] }

[EyalDelarea]

Hey @debben, Thanks for reporting this issue.

This PR should fix the missing ID issue : https://github.com/jfrog/jfrog-cli-core/pull/1201.

Will update you here once the fix is released.

[lincoohe]

Hi @EyalDelarea When is it expected to be released? Looking forward to your reply，Thanks!

[kunkka-m]

Also look forward to its release asap, thanks!

      On Mon, July 29 2024 at  2:20 PM felix ***@***.***> wrote:

Hi @EyalDelarea When is it expected to be released? Looking forward to your reply，Thanks!

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[RobiNino]

Hi @lincoohe , @kunkka-m , We unfortunately had to revert this fix because we found out it breaks the default module name for a few packages managers. We will now work on fixing the PR so we can release the fix as soon as possible. I apologize for the inconvenience caused by this, thank you for your patience.

[zewa666]

any updates on this one?