HarperFast / HarperFast/rocksdb-prebuilds

Experimental-patch PR gate applies HEAD's official patches to an older pinned tag

Open
#25 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
BitBake
Stars
1
Forks
1
Avg merge
6d 7h
Merged PRs (30d)
3

Description

## Summary

The experimental-patch PR gate applies **`HEAD`'s official patches** to the **experimental patch's pinned RocksDB tag**. That couples unrelated PRs: rebasing an official vcpkg patch for a newer RocksDB is blocked until every experimental patch is rebased too.

## Sequence

1. `experimental-patches/0001-cf-blob-dir/patched-version.txt` pins `v11.8.1`.
2. Someone rebases `vcpkg-overlays/rocksdb/patches/0001-fix-dependencies.patch` for a newer RocksDB release. That PR touches `vcpkg-overlays/rocksdb/**`, which is a trigger path for the gate.
3. The gate downloads **v11.8.1** (the experimental patch's pin) and applies the **new** official patch to it.
4. The new official patch does not apply at `-F0` to the older tree, so the gate fails.
5. The official-patch PR is blocked, for a reason that has nothing to do with it.

## Why it is filed separately

Not introduced by [#24](https://github.com/HarperFast/rocksdb-prebuilds/pull/24) — the gate [#13](https://github.com/HarperFast/rocksdb-prebuilds/pull/13) added had the same behaviour, applying `vcpkg-overlays/rocksdb/patches/*.patch` to `patched-version.txt`'s tag. #24 moved that logic into `.github/scripts/apply-patches.sh` without changing it. Surfaced by the cross-model review of #24; filing separately rather than expanding that PR's scope.

Note this only becomes reachable once #13 and #24 merge — there is nothing to fix on `main` today.

## Options

- Give the official patches their own pin, and have the gate apply each patch set at the version it targets.
- Validate an experimental patch against its pin using the official patches **as of that pin** (`git show :...`) rather than `HEAD`'s.
- Accept the coupling and require experimental patches to be rebased alongside official ones — reasonable while there is one experimental patch, less so later.

The underlying tension is that `patched-version.txt` pins a version for the experimental patch, while the official patches implicitly track latest. Whichever option is chosen, those two should be made explicit rather than left to interact by accident.

Contributor guide

Open the contributing guide

Research direction

Start with .github/scripts/apply-patches.sh and the workflow for the experimental-patch PR gate, then inspect experimental-patches/0001-cf-blob-dir/patched-version.txt and vcpkg-overlays/rocksdb/patches/. Review #13 and #24 for the current behavior, noting that the issue is not reachable on main until they merge. Done means the chosen patch-version policy is explicit and the gate no longer applies unrelated HEAD patches to an older pinned tag.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github-actions, shell
Domain
build-system, ci-cd
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.