refresh-fork

Rebase Marin external fork pins onto newer upstream bases and validate them with end-to-end tests.

3.2k|266|Updated Mar 22, 2024
One-click install
npx skills add https://github.com/marin-community/marin --skill refresh-fork
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: refresh-fork
Source: https://github.com/marin-community/marin/tree/main/.agents/skills/refresh-fork
Command: npx skills add https://github.com/marin-community/marin --skill refresh-fork

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Keeping Marin's pinned external forks (vllm, tpu-inference, evalchemy, harbor, MarinSkyRL, XLA) current with upstream requires a careful rebase of overlay patches, re-pinning, and validation; doing this by hand risks lost patches, broken pins, and unvalidated releases.

Core Features & Use Cases

  • Descriptor-driven refresh: Reads each fork's section in config/external/migration.toml to select the new upstream base (upstream main, latest GitHub release, or a derived SHA) and determine the pin mechanism.
  • Overlay rebase with audit: Replays carry/fix commits onto <branch>-next, classifies each patch as carry/drop/fix, and audits the result with git range-diff and API call-site checks.
  • Validated promotion workflow: Runs the fork's own CI suite and the descriptor's Marin end-to-end test, creates rollback and date tags, opens one draft PR, and names the required admin hard-swap promotion.
  • Use Case: A weekly automation run refreshes the vllm/tpu-inference group onto the newest tpu-inference release, validates it with the Qwen3 TPU serve-and-eval smoke test, and opens a single draft PR for admin review.

Quick Start

Ask the agent to refresh the vllm fork pin onto the latest upstream base and open the draft Marin PR after the end-to-end test passes.

Frequently Asked Questions about refresh-fork

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refresh a Marin external fork pin to a newer upstream base?

Read the fork's section in config/external/migration.toml, select the new base per its base_select rule, rebase the overlay onto <branch>-next, re-pin Marin at the staged tip, run the descriptor's e2e test, and open one draft PR. An admin then hard-swaps the stable branch after review.

How are upstream bases selected for each fork?

The descriptor's base_select field controls it: upstream_main tracks the upstream default branch tip, latest_release picks the newest non-draft, non-prerelease GitHub release tagged vMAJOR.MINOR.PATCH, and derived reads a SHA from the tpu-inference release's vllm_lkg.version file.

What happens when a fork refresh is blocked?

No PR is opened. The workflow creates or updates one marin-community/marin issue assigned to the descriptor's blocker_assignee, titled with the fork and short reason, including current pins, the selected base, attempted fixes, the remaining failure, and artifacts.

Does the refresh force-push the fork's stable branch?

No. The unattended refresh stages everything on a disposable <branch>-next branch and creates rollback and date tags, but leaves the protected stable branch unchanged. An admin with ruleset bypass performs the hard swap with git push --force-with-lease after reviewing the draft PR.

Why is the XLA fork excluded from the weekly refresh?

The marin-community/xla fork's base is fixed at the XLA commit named by the pinned jax[cuda13] release, so it only changes when the jax pin changes. It is rebuilt and re-pinned manually through the marin-pjrt candidate and promotion workflows described in docs/xla.md.

What validation is required before opening the refresh PR?

The fork's own CI suite must run first, then the descriptor's Marin end-to-end test, such as the Qwen3 TPU serve-and-eval smoke for vllm or the gsm8k-smoke eval for evalchemy. A dry-run or py_compile check alone does not count as validation.