84 lines
3 KiB
Markdown
84 lines
3 KiB
Markdown
---
|
|
title: Dispatch a Codex release flow
|
|
description: Connect the OpenAI Codex release feed to a Codex patch-stack maintenance workspace.
|
|
---
|
|
|
|
# Dispatch a Codex release flow
|
|
|
|
This tutorial connects upstream OpenAI Codex releases to the Codex fork
|
|
maintenance flow. The flow rebases a maintained patch stack onto an upstream
|
|
release tag and verifies the candidate.
|
|
|
|
## 1. Use the release source
|
|
|
|
The bundled `apps/patch/feed-sources.json` includes
|
|
`github-openai-codex-releases`. Its target emits `upstream.release` events with
|
|
the upstream repository and release tag in the payload.
|
|
|
|
The maintained Codex fork should still be modeled in Git. In the neighboring
|
|
`../codex` checkout, `origin` is `https://github.com/peezy-tech/codex` and
|
|
`code-mode-exec-hooks` is the maintained patch branch.
|
|
|
|
Before running release maintenance, make sure the checkout has a canonical
|
|
upstream remote:
|
|
|
|
```bash
|
|
cd ../codex
|
|
git remote get-url upstream || git remote add upstream https://github.com/openai/codex.git
|
|
git fetch upstream --tags --prune
|
|
git fetch origin --prune
|
|
git status --short --branch
|
|
```
|
|
|
|
If `git status` shows local changes or untracked files, resolve them before an
|
|
automated rebase.
|
|
|
|
## 2. Point Patch at a workspace backend
|
|
|
|
```bash
|
|
PATCH_WORKSPACE_BACKEND_URL=http://127.0.0.1:3586 \
|
|
PATCH_WORKSPACE_BACKEND_SECRET=dev-secret \
|
|
DATA_DIR=./data \
|
|
FEED_SOURCES_PATH=./feed-sources.json \
|
|
bun run --filter @peezy.tech/patch start
|
|
```
|
|
|
|
`PATCH_WORKSPACE_BACKEND_URL` can point at the Codex workspace backend base URL
|
|
or its `/events` endpoint. Patch normalizes either HTTP form before calling the
|
|
workspace flow capability. `PATCH_FLOW_BACKEND_URL` and
|
|
`PATCH_FLOW_DISPATCH_URL` remain accepted for older feed targets.
|
|
|
|
## 3. Inspect the stored event
|
|
|
|
```bash
|
|
curl http://127.0.0.1:3000/flow-events
|
|
```
|
|
|
|
When `PATCH_ADMIN_TOKEN` is set, include either `Authorization: Bearer <token>`
|
|
or `X-Patch-Admin-Token: <token>`.
|
|
|
|
## 4. Keep completion app-owned
|
|
|
|
Patch dispatches the generic event. The installed Codex release flow or
|
|
workspace owns the work that happens next:
|
|
|
|
- fetch upstream tags
|
|
- resolve the release tag
|
|
- rebase the maintained patch branch
|
|
- collect conflict context when the rebase stops
|
|
- run the configured checks
|
|
- optionally push a candidate ref
|
|
|
|
That candidate can be used for an internal build/link workflow before a public
|
|
release exists: build the local native binary, place it in the npm wrapper's
|
|
vendor layout, and link the package with Bun. Public npm publishing should stay
|
|
a separate channel because it may need GitHub Actions, trusted publishing,
|
|
release review, and upstream schedule alignment.
|
|
|
|
For the current Codex fork, public release is the `rust-v*` tag workflow that
|
|
publishes the `@peezy.tech/*` npm packages.
|
|
|
|
In service mode, patch.moi should trigger this work through the remote forge
|
|
instead of depending on a persistent local checkout. The service creates or
|
|
updates a maintenance branch, starts a runner workflow, and records the PR,
|
|
issue, check, artifact, or candidate ref that the runner produces.
|