Package update Opensearch Dashboard 3 to 3.1.0 and use git polar to track tag instead of release

[debasishbsws]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit 93296ec81611080141bc569f761794a01eb1d105 for 3.1.0, found c152d16bbe6b4501e3e2418be0f9f8b3dc07559f

Build Details

Category	Details
Build System	Melange
Failure Point	git checkout operation in subpackage opensearch-dashboards-3-config pipeline

Root Cause Analysis 🔍

The build expected a specific Git commit hash (93296ec81611080141bc569f761794a01eb1d105) for tag 3.1.0, but found a different commit hash (c152d16bbe6b4501e3e2418be0f9f8b3dc07559f) when checking out the repository. This indicates either the tag was moved in the remote repository or the expected commit hash in the build configuration is incorrect.

---

🔍 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

• Adding VersionStream for gitlab-runner-17.11 #51032
• calico-3.29 - usrmerge usr/sbin #44671
• gitlab-runner-17.11/17.11.1 package update #52449

Suggested Changes

File: opensearch-dashboards-3.yaml

• replace at line 167 (subpackages section, opensearch-dashboards-3-config subpackage, git-checkout step)
  Original:

          expected-commit: 93296ec81611080141bc569f761794a01eb1d105 # will need to be manually updated when opensearch dashboard auto update happens

Replacement:

          expected-commit: c152d16bbe6b4501e3e2418be0f9f8b3dc07559f # will need to be manually updated when opensearch dashboard auto update happens

Click to expand fix analysis

Analysis

After analyzing the similar fixed build failures, I can see a common pattern: all involve git-checkout operations where the expected commit hash doesn't match the actual commit hash for a specific tag. In each case, the fix was to update the expected-commit value in the YAML file to match the actual commit hash that the tag points to.

The most direct cause is usually one of:

1. The tag was moved in the upstream repository (pointing to a different commit than before)
2. The expected-commit value in the YAML was incorrect to begin with
3. The tag is an annotated tag rather than a lightweight tag, causing a commit object vs tag object mismatch

In the first example (gitlab-runner), they created a new file with the updated expected-commit hash. In the second example (calico), they updated the expected-commit hash while also making other changes. In the third example (gitlab-runner), they simply updated the expected-commit hash to match the actual commit that the tag points to.

Click to expand fix explanation

Explanation

The build is failing because the expected commit hash (93296ec81611080141bc569f761794a01eb1d105) doesn't match the actual commit hash (c152d16bbe6b4501e3e2418be0f9f8b3dc07559f) for the 3.1.0 tag in the opensearch-build repository.

This mismatch can happen for several reasons:

1. The tag may have been moved in the upstream repository to point to a different commit
2. The tag might be an annotated tag (which adds a layer of indirection), rather than a lightweight tag that points directly to a commit
3. The expected-commit value in the YAML file might have been incorrect to begin with

The fix is straightforward - we need to update the expected-commit value in the subpackage's git-checkout step to match the actual commit hash that the 3.1.0 tag points to in the repository. The error message already tells us what the correct hash should be: c152d16bbe6b4501e3e2418be0f9f8b3dc07559f.

This is similar to the pattern seen in all three example fixes, where the expected-commit hash was updated to match the actual commit hash that the tag points to. The comment in the YAML file even acknowledges that this value will need manual updates when OpenSearch Dashboard versions are updated.

Click to expand alternative approaches

Alternative Approaches

• Instead of hardcoding the expected-commit hash, we could modify the build system to use a 'verify-only' mode for git checkouts that would first fetch the tag, determine its commit hash, and only fail if the content of that commit doesn't match expectations. This would be more resilient to upstream tag changes.
• We could use a specific commit hash instead of a tag for more stability, but this would make version updates more difficult.
• Another approach would be to add a verification step that checks the repository content signatures or checksums rather than relying on commit hashes, which would be more resilient to tag movements in the upstream repo.

---

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

[debasishbsws]

Closing this as they have released the version in github