update-v8-version

Name: update-v8-version
Author: openai

101kstars15kforks

How to install update-v8-version?

openai/codex/update-v8-version

$npx -y skills add openai/codex --skill update-v8-version

Installs into the current project.

Summary

Update Codex's pinned v8 / rusty_v8 versions, validate the release-candidate path, and investigate failed V8 canary or artifact builds. Use when asked to bump V8, update rusty_v8 artifacts, prepare or validate a V8 release candidate, check v8-canary, or diagnose why a V8

Files · 1

View on GitHub

SKILL.md

1	# Update V8 Version
2
3	## Core Workflow
4
5	1. Read `third_party/v8/README.md` and follow its version-bump sequence. Treat
6	that document as the release-process source of truth.
7	2. Inspect and update the concrete repo surfaces that carry the pin:
8	- `codex-rs/Cargo.toml`
9	- `codex-rs/Cargo.lock`
10	- `MODULE.bazel`
11	- `third_party/v8/BUILD.bazel`
12	- `third_party/v8/README.md`
13	- the matching `third_party/v8/rusty_v8_<version>.sha256` manifest when the
14	remaining prebuilt inputs change
15	3. Keep the existing checksum helpers in the loop:
16
17	```bash
18	python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
19	python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
20	python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py
21	```
22
23	4. Validate the release-candidate path before broadening the work:
24	- Prefer checking the `v8-canary` CI result for the candidate branch or PR
25	when one exists, using GitHub check tooling or `gh` as appropriate.
26	- If CI is unavailable or the user asked for a local-only check, run the
27	closest local validation that is practical for the changed surface and say
28	explicitly that it is a local substitute, not the full hosted canary.
29	5. If the canary path passes, stop there. Summarize the result and encourage the
30	user to commit the candidate changes or proceed with the release flow they
31	requested. Do not publish tags, releases, or pushes unless the user asked.
32
33	## Failure Path
34
35	Enter this path only when the canary or local build path fails.
36
37	1. Capture the failing target, workflow job, and first actionable error.
38	2. Compare the currently pinned version with the target version at the relevant
39	upstream tag or SHA. Inspect both:
40	- `denoland/rusty_v8`
41	- upstream V8 source at the target Bazel-pinned version
42	3. Track build-relevant deltas rather than broad source churn:
43	- generated binding layout changes
44	- archive or asset naming changes
45	- GN/Bazel target changes
46	- custom libc++ / libc++abi / llvm-libc inputs
47	- sandbox or pointer-compression feature relationships
48	- patch hunks in `patches/` that no longer apply or no longer match upstream
49	4. Trace each failing delta back into Codex's build graph:
50	- `MODULE.bazel`
51	- `third_party/v8/BUILD.bazel`
52	- `.github/scripts/rusty_v8_bazel.py`
53	- `.github/workflows/v8-canary.yml`
54	- `.github/workflows/rusty-v8-release.yml`
55	5. Update only the pieces required to restore the target version's build and
56	artifact contract. Keep patch explanations and doc changes close to the
57	affected files.
58	6. Re-run the focused validation. If it becomes green, return to the normal
59	workflow and stop with a concise summary plus the remaining release step.
60
61	## Reporting
62
63	- Say whether validation came from hosted `v8-canary` or from a local
64	substitute.
65	- Distinguish "version bump complete" from "release published".
66	- When blocked, report the upstream delta that matters, the Codex file it hits,
67	and the next concrete fix to try.

People who liked this also viewed

6 picks

Type

update-v8-version

101kstars15kforks

View on GitHub

How to install update-v8-version?

openai/codex/update-v8-version

$npx -y skills add openai/codex --skill update-v8-version

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Update V8 Version
2
3	## Core Workflow
4
5	1. Read `third_party/v8/README.md` and follow its version-bump sequence. Treat
6	that document as the release-process source of truth.
7	2. Inspect and update the concrete repo surfaces that carry the pin:
8	- `codex-rs/Cargo.toml`
9	- `codex-rs/Cargo.lock`
10	- `MODULE.bazel`
11	- `third_party/v8/BUILD.bazel`
12	- `third_party/v8/README.md`
13	- the matching `third_party/v8/rusty_v8_<version>.sha256` manifest when the
14	remaining prebuilt inputs change
15	3. Keep the existing checksum helpers in the loop:
16
17	```bash
18	python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
19	python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
20	python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py
21	```
22
23	4. Validate the release-candidate path before broadening the work:
24	- Prefer checking the `v8-canary` CI result for the candidate branch or PR
25	when one exists, using GitHub check tooling or `gh` as appropriate.
26	- If CI is unavailable or the user asked for a local-only check, run the
27	closest local validation that is practical for the changed surface and say
28	explicitly that it is a local substitute, not the full hosted canary.
29	5. If the canary path passes, stop there. Summarize the result and encourage the
30	user to commit the candidate changes or proceed with the release flow they
31	requested. Do not publish tags, releases, or pushes unless the user asked.
32
33	## Failure Path
34
35	Enter this path only when the canary or local build path fails.
36
37	1. Capture the failing target, workflow job, and first actionable error.
38	2. Compare the currently pinned version with the target version at the relevant
39	upstream tag or SHA. Inspect both:
40	- `denoland/rusty_v8`
41	- upstream V8 source at the target Bazel-pinned version
42	3. Track build-relevant deltas rather than broad source churn:
43	- generated binding layout changes
44	- archive or asset naming changes
45	- GN/Bazel target changes
46	- custom libc++ / libc++abi / llvm-libc inputs
47	- sandbox or pointer-compression feature relationships
48	- patch hunks in `patches/` that no longer apply or no longer match upstream
49	4. Trace each failing delta back into Codex's build graph:
50	- `MODULE.bazel`
51	- `third_party/v8/BUILD.bazel`
52	- `.github/scripts/rusty_v8_bazel.py`
53	- `.github/workflows/v8-canary.yml`
54	- `.github/workflows/rusty-v8-release.yml`
55	5. Update only the pieces required to restore the target version's build and
56	artifact contract. Keep patch explanations and doc changes close to the
57	affected files.
58	6. Re-run the focused validation. If it becomes green, return to the normal
59	workflow and stop with a concise summary plus the remaining release step.
60
61	## Reporting
62
63	- Say whether validation came from hosted `v8-canary` or from a local
64	substitute.
65	- Distinguish "version bump complete" from "release published".
66	- When blocked, report the upstream delta that matters, the Codex file it hits,
67	and the next concrete fix to try.

People who liked this also viewed

6 picks

Type