nextcloud-server-31/31.0.5 package update

[octo-sts[bot]]

[octo-sts[bot]]

🔄 Build Failed: Git Checkout Error

fatal: Could not parse object 'e68ddae1e3c1e4532043f07bbc1bd9d1c96aa8a1'.

Build Details

Category	Details
Build System	Git
Failure Point	git reset --hard e68ddae1e3c1e4532043f07bbc1bd9d1c96aa8a1

Root Cause Analysis 🔍

The specified Git commit hash (e68ddae1e3c1e4532043f07bbc1bd9d1c96aa8a1) does not exist in the cloned repository. This could be because the commit was removed, force-pushed away, or never existed in the specified branch.

---

🔍 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

• https://github.com/wolfi-dev/os/pull/42925

Suggested Changes

File: nextcloud-server-31.yaml

• modify at line 145-149 (git-checkout with expected-commit parameter) Original:

  - uses: git-checkout
    with:
      repository: https://github.com/nextcloud/docker
      branch: master # It's ok to use master branch here, as this is something is not build-able thing; we just copy files around.
      expected-commit: e68ddae1e3c1e4532043f07bbc1bd9d1c96aa8a1
      destination: nextcloud-docker

Replacement:

  - uses: git-checkout
    with:
      repository: https://github.com/nextcloud/docker
      branch: master # It's ok to use master branch here, as this is something is not build-able thing; we just copy files around.
      depth: 1000 # Increase depth to fetch more history
      destination: nextcloud-docker

Click to expand fix analysis

Analysis

The current build failure and the similar fixed case both involve the same issue: a Git checkout failing because it can't find a specific commit hash in the repository. In the similar fixed case (wolfi-dev/os#42925), the problem was resolved by updating the expected commit hash to a value that exists in the repository. The error occurs during a git reset --hard operation where the commit hash specified is not found in the cloned repository.

This pattern suggests that the most common solution is to update the Git reference to a commit that actually exists in the target repository. This could be done by either:

1. Updating the expected-commit parameter to a valid commit hash
2. Removing the expected-commit constraint if appropriate
3. Updating the branch or depth parameters if the commit exists but wasn't fetched due to shallow clone limits

Click to expand fix explanation

Explanation

The build failure is occurring because the specified commit hash e68ddae1e3c1e4532043f07bbc1bd9d1c96aa8a1 cannot be found in the cloned repository. This could be because:

1. The commit has been removed from the master branch via force push or rebase
2. The commit is too old and not fetched due to the default shallow clone depth
3. The commit hash may have been incorrectly specified

The suggested fix removes the expected-commit parameter and adds a depth: 1000 parameter to increase the clone depth. This approach allows the pipeline to successfully clone the repository without requiring an exact commit hash match.

Since the comment in the code states "It's ok to use master branch here, as this is something is not build-able thing; we just copy files around", this suggests that the exact commit isn't critical for functionality. The files from the latest master branch should be sufficient, and removing the commit constraint while ensuring a deeper clone should resolve the issue.

This approach matches the pattern seen in the similar fixed issue, where the fix was to update Git references to point to commits that actually exist in the repository. In that case, they updated the commit hash, but here removing the constraint is cleaner since the exact commit doesn't appear to be critical.

Click to expand alternative approaches

Alternative Approaches

• Update the expected-commit parameter to a recent valid commit hash from the repository. This would require finding a specific commit in the nextcloud/docker master branch and updating the parameter accordingly.
• Change from using the master branch to using a specific tag that is known to exist. This would provide better stability and reproducibility than using the master branch.
• If specific files from a particular version are needed, consider downloading them directly via the GitHub raw URL or using the fetch action instead of git-checkout.

---

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

[AmberArcadia]

I reworked the git checkout into a fetch pipeline to hopefully prevent this type of mistaken update again (where the commit SHA from a different repo is set).

Ref: See https://chainguard-dev.slack.com/archives/C0799FD4Q1Y/p1748449222266689