Azure Dev Ops Task version 8.2.1 causing pipeline failures

SonarQube Server / Community Build
22

Hi @RStengel,

Welcome to the community and thanks for this report!

I’ve rolled your post into the ongoing incident thread. You’ve correctly identified the problem & we’re pursuing this with ADO support. Meanwhile, re-installing the task has a good chance of succeeding.

 
HTH,
Ann

23

Reinstall appears to have resolved it for us as well, thanks.

1 Like
24

Hi, reinstalling did it! Thanks for the tip…

2 Likes
25

Re-installing the extension resolved the issue for us, we are a US based organization.

2 Likes
26

I’m thinking you’re going to need someone to test the real fix, once you figure something out with Microsoft. We are stable on 8.2.0, so I will hold off on reinstalling the extension for now, as others have validated that fixes it for them.

2 Likes
27

Hi, any updates? besides the workaround of reinstalling the extension?
Thanks

28

Hi all,

We’re still wrangling with vendor support. We’ve (unfortunately) confirmed that it’s a distribution problem on the MS/ADO side because we released 8.2.2 yesterday for another problem and people are seeing the same issue with it.

 
Ann

29

Hi all,

Same problem :

Downloading task: SonarCloudPrepare (4.2.3)
Downloading task: SonarCloudAnalyze (4.2.3)
##[error]Number of entries expected in End Of Central Directory does not correspond to number of entries in Central Directory.

30

I also noticed some strange behavior. Yesterday Goz3rr reported that he was able to partially unzip the 8.2.1 version. I found that weird, because that was not possible for the 8.2.1 download that we had received. Ours was a seemingly random binary BLOB. I wasn’t able to extract any of it using several ZIP tools. It also didn’t have the PK magic header that ZIP files (and DevOps extensions) typically have.

Then I looked at the 8.2.0 version. I was able to download that and successfully extract it. However, it also gave me an error after extraction. It appeared that download was partly corrupted, but still able to be extracted. So I already had a feeling the issue might have affected more than one version of the Sonar extension.

Anyway, if the problem really is in ADO, then it might happen again. I really hope you’re actively investigating this with Microsoft. And I hope Microsoft is able to give you a RCA and that you’ll be able to pass that on to us. I’d really like to know what’s happening here.

2 Likes
31

Hello,

We are encountering an issue in our Azure DevOps pipeline when using SonarCloud. The error occurs during the “Initialize job” phase, before any of our actual pipeline steps are executed.

Error message

Downloading task: SonarCloudPrepare (4.2.3)
Downloading task: SonarCloudAnalyze (4.2.3)
##[error]Number of entries expected in End Of Central Directory does not correspond to number of entries in Central Directory.

Context

  • CI: Azure DevOps Pipelines

  • SonarCloud tasks version: 4.2.3

  • SonarCloud integration: Enabled (SonarCloudPrepare / SonarCloudAnalyze)

  • Agent type: windows-latest

Observations

  • The error happens during job initialization, not during build or analysis steps

  • It occurs while downloading SonarCloud tasks

  • It seems related to a corrupted ZIP file (task package)

Additional information

  • The pipeline was working correctly with SonarCloud tasks v4.2.1

  • The issue started appearing after upgrading to v4.2.3

  • This suggests a potential regression or corrupted package in the newer version

Question

Are there any new parameters or configuration changes required when using SonarCloud tasks v4.2.3?
Is this a known issue or regression with version 4.2.3?

Thanks for your help!

1 Like
32

Well, it’s the exact same problem this whole topic is about. Your report seems to confirm the problem still persists with newer versions of the extension.

1 Like
33

Any updates on what you’ve heard from Microsoft?

34

Hi,

Well, the good news is that we’ve escalated through our support 3rd party through to ADO and then to the Marketplace team. The bad news is that we’re still waiting for their response.

The suggestions we’ve gotten from the intermediaries haven’t been terribly helpful but did include turning it off and back on again reinstalling which, as we’ve seen, works for some but is still a roll of the dice.

 
Ann

2 Likes
35

Hi all,

I don’t have much news for you. We’re still chasing this on our end. We’ve finally gotten to the right set of support folks and they’ve admitted that there (might be) a problem. They’re investigating.

Hopefully we’ll have a real resolution soon. In the meantime, I can only thank you for what might be left of your patience.

 
Ann

1 Like