Automate syncing FalkorDB upstream releases into falkordblite (daily PR)

[gkorland]

Automate syncing FalkorDB upstream releases into falkordblite (daily PR)

Goal

Each time FalkorDB/FalkorDB publishes a new release, we want FalkorDB/falkordblite to automatically detect it and open a PR that:

1. bumps the referenced FalkorDB upstream version everywhere it’s used in this repo, and then
2. bumps the falkordblite version accordingly.

This should require no manual bookkeeping/state file; the workflow should compare against the FalkorDB version currently referenced on the default branch.

---

Proposed solution (Option 1: polling from falkordblite)

Add a GitHub Actions workflow in FalkorDB/falkordblite that runs daily and can also be triggered manually.

Triggers

• schedule: daily (cron)
• workflow_dispatch: manual run

Behavior

1. Determine the latest upstream release tag for FalkorDB/FalkorDB via GitHub API.
2. Determine the current upstream FalkorDB version used by falkordblite by reading it from the repo’s default branch (no separate “last processed” file).
3. If the versions are the same:
   • exit successfully (no PR).
4. If the versions differ:
   • create/update a branch (idempotent, e.g. automation/bump-falkordb-<tag> or a stable branch name)
   • update/bump the FalkorDB version everywhere it is required in this repository (build scripts, vendored/submodule refs, manifests, docs—wherever the version is referenced)
   • bump falkordblite’s own version as well
   • commit changes and open (or update) a PR

PR requirements

• PR title example: chore: bump FalkorDB to <new_tag> (from <old_tag>)
• PR body must include:
  • old FalkorDB version/tag
  • new FalkorDB version/tag
  • link to the upstream release: https://github.com/FalkorDB/FalkorDB/releases/tag/<new_tag>

Implementation notes

• Prefer peter-evans/create-pull-request or gh pr create for PR creation.
• Keep workflow permissions minimal (ideally contents: write, pull-requests: write).
• Ensure reruns are safe/idempotent (don’t open duplicate PRs; update the existing one if it already exists).
• Use robust version parsing (strip leading v if needed, handle pre-releases if we decide to ignore them).

---

Acceptance criteria

• A workflow exists in FalkorDB/falkordblite that runs daily + manual.
• It detects latest FalkorDB/FalkorDB release tag via GitHub API.
• It reads the currently referenced FalkorDB version from the repo’s default branch (no external state file).
• If versions match, workflow exits successfully without creating a PR.
• If versions differ, workflow opens/updates a single PR that:
  • bumps FalkorDB version everywhere needed
  • bumps falkordblite version
  • includes old/new versions + upstream release link in PR description
• Running the workflow multiple times produces no duplicate PRs.

---

Open questions / decisions

• Should we track latest release or latest non-prerelease only?
• Where exactly are the FalkorDB version and falkordblite version defined today? (need to enumerate files and update them consistently)
• Do we want auto-merge after CI passes, or PR only?

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim #49 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @gkorland (replace 20 with the amount, and @gkorland with the user to tip).

📖 If you want to learn more, check out our documentation.