Adding VersionStream for logstash-9.3

[octo-sts]

No description provided.

[octo-sts]

🩹 Build Failed: Patch Application Failed

Hunk #1 FAILED at 245. 1 out of 1 hunk FAILED -- saving rejects to file logstash-core/build.gradle.rej

Build Details

Category	Details
Build System	melange
Failure Point	patch step - applying GHSA-3p8m-j85q-pgmj.patch to logstash-core/build.gradle

Root Cause Analysis 🔍

The patch file GHSA-3p8m-j85q-pgmj.patch could not be applied to the logstash-core/build.gradle file. Hunk #1 failed at line 245, indicating that the target code in the gradle build file has changed since the patch was created, making the patch no longer applicable to the current version of the code. This is a common issue when patches are created for one version of source code but applied to a different version where the target lines have been modified or moved.

---

🔍 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

• confluent-kafka/8.2.0.351 package update #69426

Suggested Changes

File: logstash-9.3.yaml

• version_update at line 3 (package.version field)
  Original:

version: "9.3.0"

Replacement:

version: "9.3.1"

Content:

Update to newer patch version that likely includes the security fix

• commit_update at line 78 (git-checkout expected-commit)
  Original:

expected-commit: d6b29147cf2ed1aadaa8dd798f109f344d9b63fb

Replacement:

expected-commit: [commit_hash_for_9.3.1]

Content:

Update expected commit to match v9.3.1 tag

• removal at line 80-82 (patch step in pipeline)
  Original:

  - uses: patch
    with:
      patches: GHSA-3p8m-j85q-pgmj.patch

Content:

Remove the patch step since newer version should include the fix

Click to expand fix analysis

Analysis

The common pattern across all three similar fixes is that patches failed to apply because the target source code had been updated to newer versions, making the existing patches incompatible. In all cases, the fix involved either: 1) Updating to a newer version of the source code where the patch was no longer needed (Examples #0 and #2), or 2) Replacing the failed patch with direct code modifications using sed commands or inline dependency version overrides (Example #1). The key insight is that security patches often become obsolete when upgrading to newer versions that already include the fixes.

Click to expand fix explanation

Explanation

This fix follows the same pattern as Examples #0 and #2, where updating to a newer version eliminated the need for the security patch. The GHSA-3p8m-j85q-pgmj.patch is failing to apply because the code structure at line 245 in logstash-core/build.gradle has changed since the patch was created. By updating from 9.3.0 to 9.3.1 (if available), the security vulnerability addressed by the patch should already be fixed upstream, making the patch unnecessary. This approach is cleaner than trying to manually update the patch context, as it ensures we get the official fix rather than a potentially fragile manual patch.

Click to expand alternative approaches

Alternative Approaches

• If 9.3.1 is not available, manually update the patch file by examining the current logstash-core/build.gradle at line 245 and adjusting the patch context to match the current code structure
• Replace the patch with inline sed commands in the pipeline to make the specific security-related changes directly, similar to the approach used in Example Add binutils-2.39 configuration #1
• Check if the security issue GHSA-3p8m-j85q-pgmj has been resolved in a different way in the current version and remove the patch entirely if it's no longer needed
• Update to a newer major version like 9.4.x if available, which would likely include all recent security fixes

---

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