HarperFast / HarperFast/rocksdb-prebuilds
Experimental-patch PR gate applies HEAD's official patches to an older pinned tag
- 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
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