Adding VersionStream for neo4j-2025.05

[octo-sts]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit 5f8fe0ffd86fc325b071486a9dbdde4828465926 for 2025.05.1, found c4c5bf10117a3cb210834e2ad17fb0d58819868e

Build Details

Category	Details
Build System	git
Failure Point	git checkout operation for Neo4j repository

Root Cause Analysis 🔍

The commit hash of the Neo4j tag 2025.05.1 does not match the expected commit hash specified in the build configuration. The build expects commit 5f8fe0ffd86fc325b071486a9dbdde4828465926 but found c4c5bf10117a3cb210834e2ad17fb0d58819868e instead.

---

🔍 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 neo4j-2025.03 #49517
• Adding VersionStream for gitlab-runner-17.11 #51032

Suggested Changes

File: neo4j-2025.05.yaml

• replace at line 33-36 (pipeline git-checkout)
  Original:

  - uses: git-checkout
    with:
      repository: https://github.com/neo4j/neo4j
      tag: ${{package.version}}
      expected-commit: 5f8fe0ffd86fc325b071486a9dbdde4828465926

Replacement:

  - uses: git-checkout
    with:
      repository: https://github.com/neo4j/neo4j
      tag: ${{package.version}}
      expected-commit: c4c5bf10117a3cb210834e2ad17fb0d58819868e

Click to expand fix analysis

Analysis

After analyzing the similar fixed build failures, I can see a pattern where the git tag checkout operations failed because the expected commit hash didn't match the actual commit hash that the tag points to. In both similar fixes, the solution was to update the expected-commit value in the git-checkout step to match the actual commit that the tag points to.

The issue appears to be related to how Git tags work - they can either point directly to a commit (lightweight tags) or to a tag object that then points to a commit (annotated tags). When repositories use annotated tags, the commit hash needs to match the commit that the tag object points to, not the tag object itself.

Looking at the current build failure, we see a similar pattern where the expected commit (5f8fe0ffd86fc325b071486a9dbdde4828465926) doesn't match the actual commit that the tag 2025.05.1 points to (c4c5bf10117a3cb210834e2ad17fb0d58819868e).

Click to expand fix explanation

Explanation

The build is failing because there's a mismatch between the expected commit hash specified in the configuration file and the actual commit hash that the tag 2025.05.1 points to in the Neo4j repository.

The error message clearly states:

FAIL Expected commit 5f8fe0ffd86fc325b071486a9dbdde4828465926 for 2025.05.1, found c4c5bf10117a3cb210834e2ad17fb0d58819868e

This indicates that when the build system tried to check out the tag 2025.05.1, it found that the tag points to commit c4c5bf10117a3cb210834e2ad17fb0d58819868e, but the configuration expected it to point to 5f8fe0ffd86fc325b071486a9dbdde4828465926.

Looking at both similar fixed build failures, the solution was to update the expected-commit parameter to match the actual commit hash that the tag points to. In the first fix example, they updated the expected commit for the 2025.03.0 tag, and in the second fix example, they updated the expected commit for the v17.11.0 tag.

Updating the expected-commit value to c4c5bf10117a3cb210834e2ad17fb0d58819868e will resolve the issue because it aligns the build configuration with the actual state of the Git repository. This ensures that the build system will accept the commit that the tag actually points to, allowing the checkout operation to succeed and the build to proceed.

Click to expand alternative approaches

Alternative Approaches

• Instead of just updating the expected-commit hash, we could try to use a specific commit hash directly instead of a tag. This would bypass the tag resolution completely but would make updating more difficult.
• Another approach could be to use a branch name instead of a tag, but this is less reliable as branches can move while tags are generally fixed.
• If there was a reason we specifically needed the original commit hash (5f8fe0ffd86fc325b071486a9dbdde4828465926), we could check if this is a case where the tag was moved after the package definition was created. In that case, we might want to investigate why the tag was moved.

---

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

[AmberArcadia]

This already exists in enterprise 🤔