You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -48,7 +48,7 @@ tool enforces the following order:
48
48
The following tools must be installed and available in your PATH:
49
49
50
50
| Tool | Purpose | Notes |
51
-
|------|---------|-------|
51
+
|---|---|---|
52
52
|`gh`| GitHub CLI for PRs, releases | Requires `GH_TOKEN` env var (see below) |
53
53
|`yq`| YAML processing | Must be the [Go version](https://github.com/mikefarah/yq), not the Python version |
54
54
|`jq`| JSON processing | Used by `final-release-notes.sh`|
@@ -60,7 +60,7 @@ The following tools must be installed and available in your PATH:
60
60
61
61
**Environment variables:**
62
62
63
-
-`GH_TOKEN` — A GitHub classic personal access token with `repo` scope. Required by `gh` and by the `release-push`, `create-pr`, `merge-pr`, and `tag-release` phases.
63
+
-`GH_TOKEN` — A GitHub **classic** personal access token (not fine-grained) with `repo` scope. The token is 40 characters, starting with `ghp_`. Required by `gh` and by the `release-push`, `create-pr`, `merge-pr`, and `tag-release` phases.
64
64
65
65
**SSH access:**
66
66
@@ -87,7 +87,7 @@ The following tools must be installed and available in your PATH:
87
87
88
88
The output will show the repos in dependency order:
89
89
90
-
```
90
+
```text
91
91
dws
92
92
lustre_csi_driver
93
93
lustre_fs_operator
@@ -102,6 +102,14 @@ The following tools must be installed and available in your PATH:
102
102
103
103
1. **Check Vendoring:** For each repo's master/main branch; determine whether any of them need to be re-vendored.
104
104
> **Note:** Ensure each repo is error-free before proceeding to the next repo in `repo-list`
105
+
>
106
+
> **Note:** `nnf_sos` requires the `-M` flag because it vendors multiple API versions of `dws`:
107
+
>
108
+
> ```bash
109
+
> ./release-all.sh -P master -R nnf_sos -M
110
+
> ```
111
+
>
112
+
> **Important:** Run vendoring checks on **all** repos, not just the ones you plan to release. This catches stale submodule pointers in `nnf-deploy` (e.g., a force-push on a submodule repo can leave the pointer at an orphaned commit SHA).
105
113
106
114
```bash
107
115
For each repo in `repo-list`
@@ -110,6 +118,17 @@ The following tools must be installed and available in your PATH:
110
118
111
119
2. **Create Trial Release Branch:** Create the new release branch, merge master/main to that release branch, but don't push it yet. The point of this step is to look for merge conflicts between master/main and the release branch.
112
120
121
+
>**Note:**`nnf_mfu` may report "No new changes to release"if master has no commits since the last release. This is normal — skip it in subsequent steps.
122
+
>
123
+
>**Note:**`nnf_doc` must be deferred until after `nnf_deploy` is tagged and its GitHub Release is published. The `nnf_doc` script updates `mkdocs.yml` with the latest `nnf-deploy` release version by querying GitHub Releases (not just tags). Follow this sequence:
124
+
>
125
+
> 1. Complete Steps 2–3d for all repos through `nnf_deploy`
126
+
> 2. **Wait ~60 seconds**for`nnf_deploy`'s "Handle Release Tag" GitHub Actions workflow to publish the GitHub Release
> **Important:** `nnf_doc`'s repo is `NearNodeFlash/NearNodeFlash.github.io` and uses the `main` branch (not `master`).
131
+
113
132
```bash
114
133
For each repo in`repo-list`
115
134
./release-all.sh -P release -R $repo
@@ -153,6 +172,14 @@ The following tools must be installed and available in your PATH:
153
172
**Step 3c** — Merge PR for the pushed release branch:
154
173
155
174
>**Warning:** Do NOT manually merge the PR. Let `release-all.sh` merge it. If you accidentally merge manually, the `tag-release` phase may not find the expected merge commit message — use `-x force-tag=vX.Y.Z` to recover (see step 3d).
175
+
>
176
+
>**Note:**`merge-pr` may produce no visible output even on success. Verify the merge completed:
177
+
>
178
+
>```bash
179
+
> gh api repos/<owner>/<repo>/pulls/<pr_number>2>&1| grep -o '"merged":[^,]*'
180
+
>```
181
+
>
182
+
> Expected output: `"merged":true`
156
183
157
184
```bash
158
185
./release-all.sh -P merge-pr -R <repo>
@@ -161,6 +188,8 @@ The following tools must be installed and available in your PATH:
161
188
**Step 3d** — Tag the release:
162
189
163
190
>**Important:** This creates an **annotated** git tag. The CI/CD workflow (`handle_release_tag.yaml`) verifies that the tag is annotated and will reject lightweight tags. After tagging, the CI/CD workflow automatically creates the GitHub release with auto-generated release notes and attaches build artifacts (e.g., `manifests.tar`for`nnf-deploy`).
191
+
>
192
+
>**Note:**`tag-release` output will include "Bypassed rule violations for refs/tags/...". This is expected. All NNF repos have tag protection rulesets that block creation, update, and deletion of `v*` tags by default. Your account bypasses these rules because it has an admin or maintain role in the ruleset's bypass list. The tags are created correctly.
164
193
165
194
```bash
166
195
./release-all.sh -P tag-release -R <repo>
@@ -194,32 +223,40 @@ Finalize the release by updating the `nnf-deploy` release notes to include the r
194
223
195
224
After all repos are released and release notes are finalized, compare the new NNF release manifest to the previous release manifest. This is a recommended verification step to confirm the release contains the expected changes and catch any problems.
196
225
197
-
```console
198
-
./compare-releases.sh v0.1.6 v0.1.7
199
-
```
200
-
201
-
The output:
226
+
Use the `-i` flag to display image version changes inline:
202
227
203
228
```console
204
-
Manifest diffs for v0.1.6 to v0.1.7 are in workingspace/manifest-v0.1.6-to-v0.1.7.diff
0 commit comments