|
1 | 1 | # version-upgrade-gen |
2 | 2 |
|
3 | | -A Go tool that automates upgrading the Talos documentation to the next version. |
| 3 | +A Go tool that points the Talos documentation at a specific Talos release tag. |
4 | 4 |
|
5 | 5 | ## What it does |
6 | 6 |
|
7 | | -When run, it prompts you to select a release type and then: |
8 | | - |
9 | | -**Beta release** |
10 | | -- Updates the versioned variables block in `custom-variables.mdx` with the new beta tag (e.g. `v1.14.0-beta.0`) |
11 | | -- Adds the new `talos-vX.Y.yaml` at the bottom of the nav in all four Makefile targets so the beta version appears last in the version dropdown |
12 | | - |
13 | | -**Stable release** |
14 | | -- Updates the "latest stable" block in `custom-variables.mdx` with the new version's Kubernetes and nvidia versions (fetched from GitHub) |
15 | | -- Updates or creates the versioned variables block in `custom-variables.mdx` |
16 | | -- Updates the version warning banner to point to the new latest version |
17 | | -- Updates all canonical URLs across older version docs to point to the new version |
18 | | -- Moves the new `talos-vX.Y.yaml` to the top of the nav in all four Makefile targets |
19 | | -- Updates `TALOSCTL_IMAGE` and `TALOS_VERSION` in the Makefile |
| 7 | +You pass the exact target image tag with `--tag` (e.g. `v1.14.0-beta.0` or |
| 8 | +`v1.14.0`). The tool reads the current tag from `TALOSCTL_IMAGE` in the Makefile |
| 9 | +and derives everything else from the two tags: |
| 10 | + |
| 11 | +- **Stage** (alpha / beta / stable) comes from the tag's suffix — there is no |
| 12 | + interactive prompt. |
| 13 | +- **Folder** (`TALOS_VERSION`, e.g. `v1.14`) is the tag's `major.minor`. Moving a |
| 14 | + minor through alpha → beta → stable keeps the same folder; only a genuinely new |
| 15 | + minor changes it. |
| 16 | + |
| 17 | +**Pre-release target (alpha/beta)** |
| 18 | +- Rewrites `TALOSCTL_IMAGE` to the exact tag and `TALOS_VERSION` to the folder minor |
| 19 | +- Updates (or appends) the versioned variables block in `custom-variables.mdx` with the tag |
| 20 | +- Leaves the "latest stable" pointer (banner, canonical URLs, latest-stable block) untouched |
| 21 | +- **Navigation differs by stage:** |
| 22 | + - **alpha** — leaves the `docs.json`/`check-missing` nav lists unchanged. The reference |
| 23 | + docs are still generated on disk, but the version stays out of the published nav. |
| 24 | + - **beta** — ensures `talos-vX.Y.yaml` is present at the bottom of the nav in all four |
| 25 | + Makefile targets so the version appears last in the dropdown. This is idempotent, so |
| 26 | + a beta correctly adds the entry that an earlier alpha of the same minor skipped. |
| 27 | + |
| 28 | +**Stable target** |
| 29 | +- Rewrites `TALOSCTL_IMAGE` to the exact tag and `TALOS_VERSION` to the folder minor |
| 30 | +- Updates the "latest stable" block in `custom-variables.mdx` with the release's |
| 31 | + Kubernetes (from the `siderolabs/talos` release notes) and nvidia versions, and |
| 32 | + updates/creates the versioned block |
| 33 | +- Only when the latest stable minor actually changes (read from the version warning |
| 34 | + banner, not from `TALOS_VERSION`): updates the banner, rewrites canonical URLs |
| 35 | + across older version docs, and moves `talos-vX.Y.yaml` to the top of the nav |
| 36 | + |
| 37 | +**nvidia values (both paths)** |
| 38 | +The `nvidia_container_toolkit_release` / `nvidia_driver_release` values are resolved |
| 39 | +the same way everywhere: first from the `siderolabs/extensions` release notes for the |
| 40 | +exact tag, and — if that release is missing, has no nvidia fields, or the fetch fails — |
| 41 | +falling back to the current unversioned latest-stable values. They are therefore never |
| 42 | +written empty, and a stable run no longer aborts when the extensions data lags behind. |
| 43 | +For an existing versioned block, a pre-release only backfills nvidia values that are |
| 44 | +currently empty, so good values from an earlier stable run are never overwritten. |
| 45 | + |
| 46 | +The current image tag is matched in full, including any pre-release suffix, so a pin |
| 47 | +like `v1.14.0-alpha.2` is replaced cleanly rather than by prefix. |
20 | 48 |
|
21 | 49 | ## Usage |
22 | 50 |
|
23 | | -From the repo root: |
| 51 | +From the repo root, pass the target tag with `TAG=`: |
24 | 52 |
|
25 | 53 | ```bash |
26 | | -# Using local Go build |
27 | | -make upgrade-talos-version-local |
| 54 | +# Published Docker container |
| 55 | +make upgrade-talos-version TAG=v1.14.0-beta.0 # beta of the current minor |
| 56 | +make upgrade-talos-version TAG=v1.14.0 # stable |
| 57 | +make upgrade-talos-version TAG=v1.15.0-beta.0 # first beta of a new minor |
28 | 58 |
|
29 | | -# Using published Docker container |
30 | | -make upgrade-talos-version |
| 59 | +# Local Go build |
| 60 | +make upgrade-talos-version-local TAG=v1.14.0-beta.0 |
31 | 61 | ``` |
32 | 62 |
|
33 | | -Both commands will prompt you interactively: |
| 63 | +After the tool rewrites the pins, the Makefile targets automatically regenerate the |
| 64 | +Talos reference docs (`make generate-talos-reference`), the changelog, and |
| 65 | +`docs.json`, then tell you to run `make preview` to verify the result. |
34 | 66 |
|
35 | | -``` |
36 | | -What type of release is this? |
37 | | - [1] Beta - e.g v1.14.0-beta.0 |
38 | | - [2] Stable - e.g v1.14.0 |
| 67 | +Running the binary directly: |
39 | 68 |
|
40 | | -Enter your choice (1 or 2): |
| 69 | +```bash |
| 70 | +go run . --workspace .. --tag v1.14.0-beta.0 |
41 | 71 | ``` |
42 | 72 |
|
43 | | -After the tool runs, it automatically regenerates the changelog and `docs.json`, then tells you to run `make preview` to verify the result. |
44 | | - |
45 | 73 | ## Prerequisites |
46 | 74 |
|
47 | | -- A `talos-vX.Y.yaml` navigation file must already exist before running in either mode |
48 | | -- For stable releases, a `GITHUB_TOKEN` environment variable is recommended to avoid GitHub API rate limits |
| 75 | +- A `talos-vX.Y.yaml` navigation file must already exist before running |
| 76 | +- A `GITHUB_TOKEN` is used for the stable release GitHub lookups (and by the |
| 77 | + changelog step). The Makefile auto-fills it from `gh auth token` when it isn't |
| 78 | + already set in the environment, so no manual export is normally needed. |
49 | 79 |
|
50 | 80 | ## Building the container |
51 | 81 |
|
|
0 commit comments