sonarqube-10/25.6.0.109173 package update

[octo-sts]

[octo-sts]

🩹 Build Failed: Patch Application Failed

Hunk #1 FAILED at 327. 1 out of 1 hunk FAILED -- saving rejects to file build.gradle.rej

Build Details

Category	Details
Build System	melange
Failure Point	patch application (SONAR-25149 Upgrade text plugins to version 2.24.0.6480)

Root Cause Analysis 🔍

The patch file for SONAR-25149 could not be applied to build.gradle. The patch expected the file to look one way at line 327, but the actual file content was different. This is likely because the SonarQube 10 build.gradle file has changes that conflict with the patch being applied.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Similar PRs with fixes

• sonarqube-10/25.2.0.102705 package update #41189
• Adding VersionStream for kafka-4.0 #48244

Suggested Changes

File: sonarqube-10.yaml

• modification at line 12-13 (pipeline section, patch step)
  Original:

  - uses: patch
    with:
      patches: sonar-eclipse-GHSA-vrpq-qp53-qv56.patch sonar-text-plugin-GHSA-vrpq-qp53-qv56.patch

Replacement:

  - uses: patch
    with:
      patches: sonar-eclipse-GHSA-vrpq-qp53-qv56.patch

• addition at line after pipeline section (after the patch step and before the build step)
  Content:

  - name: modify-build-gradle-directly
    runs: |
      # Apply the text plugin update directly instead of using a patch
      sed -i 's/textVersion = "2.24.0.6400"/textVersion = "2.24.0.6480"/' build.gradle
      # Verify the change was made
      grep -q 'textVersion = "2.24.0.6480"' build.gradle

Click to expand fix analysis

Analysis

After analyzing the similar fixed build failures, I observe a common pattern: patch application failures typically occur when the target file has changed in newer versions, causing the patch context to no longer match. In both similar fixed examples, the solution was to either:

1. Update the package version and remove the problematic patch file entirely (Example #0)
2. Create a completely new package definition rather than trying to patch an existing one (Example Add binutils-2.39 configuration #1)

The current failure involves a patch for SONAR-25149 that tries to update text plugins to version 2.24.0.6480, but the patch is failing to apply to build.gradle at line 327. This suggests that the build.gradle file in the current SonarQube version (25.6.0.109173) has content that differs from what the patch expects.

Click to expand fix explanation

Explanation

The suggested fix addresses the root cause by avoiding the problematic patch application that's failing. Instead of trying to apply the patch file for the text plugin update (which is failing at line 327 of build.gradle), we're directly modifying the build.gradle file using a sed command to make the specific change that the patch was trying to make.

This approach works because:

1. The error message indicates that the patch is trying to update the text plugins to version 2.24.0.6480.
2. The most likely scenario is that the patch was created for an earlier version of the file where the text plugin version was at 2.24.0.6400 (or similar), and it's trying to update it to 2.24.0.6480.
3. By using sed to directly search and replace the version string, we bypass the context matching problems that patches have when files change.
4. We keep the other patch (sonar-eclipse-GHSA-vrpq-qp53-qv56.patch) which presumably is still applying correctly.
5. The grep command verifies that our sed replacement worked correctly before proceeding to the build step.

This solution maintains the security update intended by the patch (updating to version 2.24.0.6480) while avoiding the patch application failure caused by changes in the build.gradle file context.

Click to expand alternative approaches

Alternative Approaches

• Update to a newer version of SonarQube where the text plugin may already be at the required version, similar to Example #0 where they upgraded from 25.1.0.102122 to 25.2.0.102705 and removed the problematic patch.
• Regenerate the patch file against the current version of build.gradle to ensure the context lines match correctly.
• Check if there are other text plugin version references in other files that might also need updating alongside build.gradle, and apply those changes directly as well.

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[debasishbsws]

Hold

❓ Does anyone have any insight or reference on how SonarQube manages its releases?
According to end-of-life dates, the latest Active Supported version appears to be 10.7.0. However, if you examine their Git tags, that version was released around last September. And I guess since then, they seem to have switched to a Year-month-based versioning scheme — e.g. we're now seeing versions like: 24.12.x.xx,25.1.x.xx, etc.
Our sonarqube-10 package is also following this newer date-based versioning. which I think is not correct

[debasishbsws]

Question in upstream https://community.sonarsource.com/t/sonarqube-server-2025-release-1-2-lta/141905/4?u=debasish_biswas

Here is some Licence change announcement: https://community.sonarsource.com/t/a-new-sonar-license-for-sonarqube-analyzers/130731

also: https://community.sonarsource.com/t/sonarqube-community-build-24-12-0-100206-released/131515

We’re making some changes with the SonarQube Community build:
SonarQube Community Build will be released monthly and it adopts a new Calendar versioning.

[debasishbsws]

closing this