mirror of
https://github.com/luxfi/explore.git
synced 2026-09-24 00:28:18 +00:00
AI: migrate slash commands to skills
This commit is contained in:
tom
@@ -1,39 +0,0 @@
|
||||
# Create PR
|
||||
|
||||
## Overview
|
||||
Create a well-structured pull request with proper description, labels, and reviewers.
|
||||
|
||||
## Steps
|
||||
|
||||
_Note_ in the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`
|
||||
|
||||
1. **Check that the pull request is not already open in the remote repository**
|
||||
- If it is opened, write only PR summary (see step 3) and skip all other steps
|
||||
|
||||
2. **Prepare branch**
|
||||
- Ensure all changes are committed
|
||||
- Push branch to remote
|
||||
- Verify branch is up to date with main
|
||||
|
||||
3. **Write PR description**
|
||||
- Use template from `./docs/PULL_REQUEST_TEMPLATE.md`
|
||||
- Check if the branch name contains an issue number (use the regexp `/issue-\d+/`)
|
||||
- If found, fetch the issue details using `gh issue view [issue_number]`
|
||||
- Include "Resolves #[issue_number]" at the very beginning of the description (in the "Description and Related Issue(s)" section)
|
||||
- Summarize the changes clearly and concisely, using no more than two paragraphs. If necessary, use bullet points to highlight the main changes in the codebase. Be precise, this description should not be very long.
|
||||
- List any changes in the environment variables (look at the `./docs/ENVS.md` file) in a separate section, describe purpose of each variable change
|
||||
- Bad example: "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` environment variable to the documentation"
|
||||
- Good example: "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` to group transaction fees into one section on the transaction page"
|
||||
- Good example: "Extended possible values for `NEXT_PUBLIC_VIEWS_TX_ADDITIONAL_FIELDS` with set_max_gas_limit to display the maximum gas price set by the transaction sender"
|
||||
- Good example: "Introduced a new option, `"fee reception"`, for the `NEXT_PUBLIC_NETWORK_VERIFICATION_TYPE` variable"
|
||||
- Keep the "Checklist for PR Author" section and check the appropriate items in it.
|
||||
- When finished, ask the user for confirmation or changes before moving on to the next step.
|
||||
|
||||
4. **Set up PR**
|
||||
- Create a pull request with a descriptive title. Use draft mode for the pull request if specified in the prompt.
|
||||
- Add appropriate labels
|
||||
- If something has added or changed in `./docs/ENVS.md` file, add label "ENVs"
|
||||
- If the `package.json` file has changed, add label "dependencies"
|
||||
- If the branch name has the issue number (use the regexp `/issue-\d+/`), copy all tags from the related issue
|
||||
- Include a link to the created pull request in the command output.
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
# Deploy demo
|
||||
|
||||
## Overview
|
||||
Create Github deployment for current branch using `.github/workflows/deploy-review.yml` workflow.
|
||||
|
||||
## Steps
|
||||
|
||||
_Note_ in the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`
|
||||
|
||||
1. **Ensure all changes are pushed to remote**
|
||||
|
||||
2. **Check if there is a running deployment workflow for current branch**
|
||||
- If yes, abort the command
|
||||
|
||||
3. **Detect value for "envs_preset" workflow input**
|
||||
- Get all possible options from workflow file
|
||||
- Figure out from the prompt with which preset user wants to deploy demo. Examples:
|
||||
- "/deploy-demo for base" - preset name "base"
|
||||
- "/deploy-demo using main preset" - preset name "main"
|
||||
- "/deploy-demo without preset" - preset name "none"
|
||||
- Be aware that this input is optional, and if user didn't mention any preset, skip this step completely
|
||||
- If the preset is not listed in the worklow input options, notify user and abort the command
|
||||
|
||||
4. **Run workflow from the current branch with appropriate inputs**
|
||||
- Get the workflow run ID after triggering
|
||||
|
||||
5. **Monitor workflow execution**
|
||||
- Watch the workflow run until it completes (use `gh run watch`)
|
||||
- Track the workflow status (success, failure, cancelled)
|
||||
- Once completed, retrieve the workflow outputs and deployment URL
|
||||
|
||||
6. **Send system notification with results**
|
||||
- On workflow start: notify that deployment has been triggered
|
||||
- On workflow completion: notify with final status (success/failure), deployment URL if available, and any relevant outputs
|
||||
- On failure: notify about the error with details
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
# Get Checks Status
|
||||
|
||||
## Overview
|
||||
Fetch the status of the "Checks" workflow run (workflow file `.github/workflows/checks.yml`) for __current branch__.
|
||||
|
||||
## Steps
|
||||
|
||||
_Note_ in the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`
|
||||
1. **Fetch the status of the most recent workflow run**
|
||||
- Use the GitHub API to get the workflow status for the *current branch*.
|
||||
- If the workflow is pending, subscribe to its completion.
|
||||
- If the workflow has failed, retrieve the list of all failed jobs and steps.
|
||||
- If the workflow was never run for the current branch, report that and skip other steps.
|
||||
|
||||
2. **Report the status with a system notification**
|
||||
- Upon workflow completion, notify with the final status (success or failure).
|
||||
- In case of failure, notify about the error along with the list of failed jobs and steps.
|
||||
@@ -1,52 +0,0 @@
|
||||
# Prepare Release
|
||||
|
||||
## Overview
|
||||
Prepare the next release of the application.
|
||||
|
||||
## Steps
|
||||
1. **Get the next release tag name**
|
||||
- Fetch the latest release from GitHub and retrieve its name.
|
||||
- If not specified, calculate the next __minor__ version according to [semantic versioning](https://semver.org).
|
||||
- If specified, calculate the next __major__ or __patch__ version.
|
||||
|
||||
2. **Update `./docs/ENVS.md` and `./docs/DEPRECATED_ENVS.md` files**
|
||||
- In these files, update all placeholders containing "upcoming" text with the next release tag, adding a "+" at the end. Examples:
|
||||
- "upcoming" -> "v1.2.3+"
|
||||
- "<upcoming>" -> "v1.2.3+"
|
||||
|
||||
3. **Create release notes**
|
||||
- Use `./RELEASE_NOTES.md` as a reference and this release notes [link](https://github.com/blockscout/frontend/releases/tag/v2.3.0) as an example.
|
||||
- Get all commits between the head of the remote main branch and the latest release tag.
|
||||
- Use the GitHub API to draft the next release notes using the main branch as a target. Parse the response to obtain the list of pull requests and new contributors.
|
||||
- Copy `./RELEASE_NOTES.md` into a new file named `./RELEASE_NOTES_<release-tag>.md`.
|
||||
- For every section (except "Changes in ENV variables") in the file, add the appropriate pull requests from previous steps using the pattern for each line: `- <pull-request-name> by <pull-request-author> in <link-to-pull-request>`. Example: "- API documentation page by @tom2drum in https://github.com/blockscout/frontend/pull/2725". Capitalize first letter in the PR name if needed.
|
||||
- To determine the correct section in the release notes file, use the labels assigned to each pull request (which need to be fetched separately from the GitHub API alongside the pull request description, as the description will be used in the next step) and the table below. If a pull request belongs to several sections, mention it in each section. If a pull request lacks labels or its section cannot be determined, place it in the "Other Changes" section.
|
||||
|
||||
| Section | Labels |
|
||||
| --------------------------- | ----------------------------------------------- |
|
||||
| New Features | feature, enhancement, client feature |
|
||||
| Bug Fixes | bug |
|
||||
| Performance Improvements | performance |
|
||||
| Dependencies updates | dependencies |
|
||||
| Design updates | design |
|
||||
|
||||
- Compose the "Changes in ENV Variables" section following these rules:
|
||||
- Find all pull requests tagged with "ENVs."
|
||||
- Create a temporary file and paste the pull request numbers along with their descriptions, excluding the "Checklist for PR Author" section.
|
||||
- Analyze the changes made to the ENV variables based on those descriptions. Feel free to rephrase sentences if necessary. If you cannot determine the correct changes or are unsure of their accuracy, use "Cannot find any changes in ENVs in PR description" as a placeholder in the next step.
|
||||
- Compose the section according to the following template (note that changes are grouped by the related pull request number):
|
||||
```
|
||||
- <pull-request-number>:
|
||||
- <change-1>
|
||||
- <change-2>
|
||||
```
|
||||
Examples:
|
||||
- #3005
|
||||
- Added `NEXT_PUBLIC_AD_BANNER_ENABLE_SPECIFY` to enable the Specify ad provider for users with a connected wallet.
|
||||
- Removed the `hype` option from the `NEXT_PUBLIC_AD_BANNER_PROVIDER` variable values.
|
||||
- #2968
|
||||
- Added `NEXT_PUBLIC_MEGA_ETH_SOCKET_URL_METRICS` to display information on the uptime dashboard page.
|
||||
- Update the "Full list of the ENV variables" and "Full Changelog" with the correct version tags.
|
||||
- Update the "New Contributors" section if necessary.
|
||||
- Keep the "Compatibility" section unchanged.
|
||||
- Remove all empty sections.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
name: check-github-cli
|
||||
description: Ensure GitHub CLI (gh) is installed and authenticated before running gh commands; guide the user to configure it if not
|
||||
---
|
||||
# Check GitHub CLI Availability
|
||||
|
||||
Use this skill whenever a workflow or command requires the GitHub CLI (`gh`). Before running any `gh` commands:
|
||||
|
||||
1. **Check installation and auth**: Run `gh auth status`. If it reports "not logged in" or the command is not found:
|
||||
- **If `gh` is not installed**: Ask the user to install it (e.g. `brew install gh` on macOS, or see [GitHub CLI](https://cli.github.com/)) and then authenticate.
|
||||
- **If `gh` is installed but not configured**: Ask the user to configure it themselves. Provide these instructions to help them:
|
||||
- Run `gh auth login` and follow the prompts (choose HTTPS or SSH, authenticate via browser or token).
|
||||
- Ensure the account has the permissions needed for the operation (e.g. read access to the repository, or read/write if the task requires it).
|
||||
- Do not attempt to authenticate on the user's behalf; only guide them with the commands and link to [GitHub CLI authentication docs](https://cli.github.com/manual/gh_auth_login).
|
||||
2. **If `gh auth status` succeeds**: Proceed with the steps that require `gh`.
|
||||
|
||||
Other skills that depend on `gh` (e.g. get-checks-status) should instruct the agent to ensure GitHub CLI is ready first by following this skill.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
name: create-pr
|
||||
description: Create a well-structured pull request with proper description, labels, and reviewers
|
||||
disable-model-invocation: true
|
||||
---
|
||||
# Create PR
|
||||
|
||||
## Prerequisites: GitHub CLI
|
||||
|
||||
This workflow uses `gh` to check for existing PRs, fetch issue details, and create the PR. **Follow the check-github-cli skill** first (ensure `gh auth status` succeeds; if not, guide the user to install/configure `gh` and do not proceed). The account needs read access to the repo and write access to create PRs and manage labels.
|
||||
|
||||
## Overview
|
||||
|
||||
Create a well-structured pull request with proper description, labels, and reviewers.
|
||||
|
||||
## Steps
|
||||
|
||||
_Note:_ In the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`.
|
||||
|
||||
### 1. Check that a PR is not already open for this branch
|
||||
|
||||
- Get the current branch: `git branch --show-current`.
|
||||
- List open PRs for that branch: `gh pr list --head <BRANCH> --state open`.
|
||||
- If a PR exists, do **only** the PR summary (see step 3: write the description content as if for the PR, but do not create or update the PR). Skip steps 2, 3 (create/update), and 4. Tell the user the PR is already open and link to it.
|
||||
|
||||
### 2. Prepare the branch
|
||||
|
||||
- Ensure all changes are committed:
|
||||
- `git status` to see uncommitted changes.
|
||||
- If there are changes: `git add` (as appropriate), then `git commit -m "..."` with a clear message.
|
||||
- Push the branch: `git push -u origin <BRANCH>` (or `git push` if upstream is already set).
|
||||
- Verify the branch is up to date with main:
|
||||
- `git fetch origin main` then compare: e.g. `git rev-list --left-right --count origin/main...HEAD` (expect `0 N` for “main has nothing we don’t have”) or merge/rebase if the user wants: `git merge origin/main`.
|
||||
- Resolve any merge conflicts before continuing.
|
||||
|
||||
### 3. Write the PR description
|
||||
|
||||
- Use the template from `./docs/PULL_REQUEST_TEMPLATE.md` as the base. Read it and fill in each section.
|
||||
- **Issue number from branch name:** If the branch name matches the pattern `issue-\d+` (e.g. `issue-123`), extract the number (e.g. `git branch --show-current | grep -oE 'issue-[0-9]+' | grep -oE '[0-9]+'`), then:
|
||||
- Fetch the issue: `gh issue view <ISSUE_NUMBER>`.
|
||||
- At the very beginning of the **"Description and Related Issue(s)"** section, include: `Resolves #<ISSUE_NUMBER>`.
|
||||
- **Summary of changes:** Summarize the changes clearly and concisely in no more than two paragraphs. Use bullet points if needed. Be precise; keep the description short.
|
||||
- **Environment variable changes:** If any env vars were added, changed, or documented:
|
||||
- Compare or read `./docs/ENVS.md` (and the validator/ENVS docs if relevant) to list what changed.
|
||||
- Add a separate section listing each variable change and the **purpose** of each (why it was added/changed).
|
||||
- **Bad:** "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` environment variable to the documentation."
|
||||
- **Good:** "Added `NEXT_PUBLIC_VIEWS_TX_GROUPED_FEES` to group transaction fees into one section on the transaction page."
|
||||
- **Good:** "Extended possible values for `NEXT_PUBLIC_VIEWS_TX_ADDITIONAL_FIELDS` with set_max_gas_limit to display the maximum gas price set by the transaction sender."
|
||||
- **Good:** "Introduced a new option, `"fee reception"`, for the `NEXT_PUBLIC_NETWORK_VERIFICATION_TYPE` variable."
|
||||
- **Checklist:** Keep the "Checklist for PR Author" section from the template and check the items that apply (e.g. tested locally, tests added, ENVS/docs/validator updated if env vars changed).
|
||||
- When the description is ready, **ask the user for confirmation or changes** before creating the PR (step 4).
|
||||
|
||||
### 4. Create the PR and set labels
|
||||
|
||||
- Create the pull request with a descriptive title. Use draft mode if the user asked for it:
|
||||
- `gh pr create --title "Your descriptive title" --body-file /path/to/body.md` (and add `--draft` if draft).
|
||||
- Or paste the body inline if preferred; ensure the filled template is used.
|
||||
- Add labels:
|
||||
- If anything was added or changed in `./docs/ENVS.md`, add the **"ENVs"** label: `gh pr edit <PR_NUMBER> --add-label "ENVs"` (or add labels during `gh pr create` if your `gh` version supports it).
|
||||
- If `package.json` has changed (check with `git diff origin/main -- package.json`), add the **"dependencies"** label.
|
||||
- If the branch name contained an issue number (pattern `issue-\d+`), copy all labels from that issue onto the PR: get labels with `gh issue view <ISSUE_NUMBER> --json labels -q '.labels[].name'`, then add each: `gh pr edit <PR_NUMBER> --add-label "<LABEL>"`.
|
||||
- Include a clickable link to the created PR in the command output (e.g. from `gh pr view --web` or the URL printed by `gh pr create`).
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: deploy-demo
|
||||
description: Create a GitHub deployment for the current branch using the deploy-review workflow
|
||||
disable-model-invocation: true
|
||||
---
|
||||
# Deploy demo
|
||||
|
||||
## Prerequisites: GitHub CLI
|
||||
|
||||
This workflow uses `gh` to trigger and monitor the deployment workflow. **Follow the check-github-cli skill** first (ensure `gh auth status` succeeds; if not, guide the user to install/configure `gh` and do not proceed). The account needs permission to trigger workflows and read the repository.
|
||||
|
||||
## Overview
|
||||
|
||||
Create a GitHub deployment for the current branch using `.github/workflows/deploy-review.yml` (workflow name: "Deploy review environment").
|
||||
|
||||
## Steps
|
||||
|
||||
_Note:_ In the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`.
|
||||
|
||||
### 1. Ensure all changes are pushed to remote
|
||||
|
||||
- Check status: `git status`. If there are uncommitted changes, ask the user to commit and push, or run `git add` / `git commit` and then push.
|
||||
- Push the current branch: `git push origin $(git branch --show-current)` (or `git push` if upstream is set). Abort if push fails.
|
||||
|
||||
### 2. Check for an already running deployment for the current branch
|
||||
|
||||
- Get current branch: `git branch --show-current`.
|
||||
- List runs for the deploy-review workflow on this branch that are in progress or queued:
|
||||
- `gh run list --workflow=deploy-review.yml --branch <BRANCH> --status in_progress`
|
||||
- `gh run list --workflow=deploy-review.yml --branch <BRANCH> --status queued`
|
||||
- If any run is returned, **abort the command** and tell the user a deployment is already running for this branch (include a link to the run).
|
||||
|
||||
### 3. Resolve the "envs_preset" workflow input (optional)
|
||||
|
||||
- **Get valid options from the workflow file (single source of truth):** Read `.github/workflows/deploy-review.yml` and extract the list of allowed values from `on.workflow_dispatch.inputs.envs_preset.options` (the YAML array under that key). Do not hardcode or copy the preset list into this skill — always read it from the file.
|
||||
- Infer from the user’s prompt which preset they want. Examples:
|
||||
- "deploy a demo for base" or "deploy with base preset" → preset `base`
|
||||
- "spin up a demo using main preset" → preset `main`
|
||||
- **If the user did not mention any preset:** skip passing `envs_preset` (the workflow uses its default).
|
||||
- **Validate the chosen preset:** Check that the user’s chosen preset is one of the values in the options list you extracted from the workflow file. If it is not in that list, notify the user (you can show the valid options from the file) and **abort the command**.
|
||||
|
||||
### 4. Trigger the workflow and capture the run ID
|
||||
|
||||
- Run the workflow from the current branch (use the branch name from step 1 or 2):
|
||||
- Without preset: `gh workflow run deploy-review.yml --ref <BRANCH>`
|
||||
- With preset: `gh workflow run deploy-review.yml --ref <BRANCH> -f envs_preset=<PRESET>`
|
||||
- The CLI does not print the new run ID. To get it: wait a few seconds, then list the latest run for this workflow and branch: `gh run list --workflow=deploy-review.yml --branch <BRANCH> --limit 1`. Use that run’s ID for the next steps.
|
||||
|
||||
### 5. Monitor the workflow until it completes
|
||||
|
||||
- Watch the run: `gh run watch <RUN_ID>` (polls until completion).
|
||||
- Track the outcome: success, failure, or cancelled (from the watch output or from `gh run view <RUN_ID>`).
|
||||
- When completed, get outputs and deployment URL: `gh run view <RUN_ID>` and, if available, `gh run view <RUN_ID> --log` or job outputs. The deployment URL may appear in the workflow summary or in job outputs; extract it and include it in the notification.
|
||||
|
||||
### 6. Send system notifications with results
|
||||
|
||||
- **When the workflow is triggered:** Notify the user that the deployment has been started (include a link to the run).
|
||||
- **When the workflow completes:** Notify with the final status (success, failure, or cancelled), the deployment URL if available, and any other relevant outputs.
|
||||
- **On failure:** Notify with the error and details (e.g. failed job/step from `gh run view <RUN_ID>` or `gh run view <RUN_ID> --log-failed`).
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: get-checks-status
|
||||
description: Fetch the status of the Checks workflow for the current branch and report with optional system notification
|
||||
disable-model-invocation: true
|
||||
---
|
||||
# Get Checks Status
|
||||
|
||||
## Prerequisites: GitHub CLI
|
||||
|
||||
Before running any steps, ensure the GitHub CLI is available and authenticated. **Follow the check-github-cli skill** (ensure `gh auth status` succeeds; if not, guide the user to install/configure `gh` and do not proceed). For this workflow, the account needs read access to the repository.
|
||||
|
||||
## Overview
|
||||
|
||||
Fetch the status of the "Checks" workflow run (workflow file `.github/workflows/checks.yml`) for __current branch__.
|
||||
|
||||
## Steps
|
||||
|
||||
_Note_ in the command output, format all URLs as clickable Markdown links: `[Link Text](URL)`
|
||||
|
||||
1. **Determine the current branch**
|
||||
- Run: `git branch --show-current` (or equivalent) to get the branch name. Use this in subsequent `gh` commands.
|
||||
|
||||
2. **Fetch the status of the most recent workflow run**
|
||||
- List the latest run for the Checks workflow on the current branch:
|
||||
- `gh run list --workflow=checks.yml --branch <BRANCH> --limit 1`
|
||||
- If no runs are returned, report that the workflow was never run for the current branch and skip other steps.
|
||||
- If a run exists, get its status and run ID, then:
|
||||
- **If the workflow is pending (queued or in progress)**: Use `gh run watch <RUN_ID>` to subscribe to completion (or poll with `gh run view <RUN_ID>` until status is completed).
|
||||
- **If the workflow has failed**: Retrieve failed jobs and steps with:
|
||||
- `gh run view <RUN_ID>` for summary and job list.
|
||||
- `gh run view <RUN_ID> --log-failed` for failed step logs (optional, for details).
|
||||
- Format the run URL as a Markdown link, e.g. `gh run view <RUN_ID> --web` gives the URL; or use: `https://github.com/<OWNER>/<REPO>/actions/runs/<RUN_ID>`.
|
||||
|
||||
3. **Report the status with a system notification**
|
||||
- Upon workflow completion, notify with the final status (success or failure).
|
||||
- In case of failure, notify about the error along with the list of failed jobs and steps.
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
name: prepare-release
|
||||
description: Prepare the next release of the application (tag, docs, release notes)
|
||||
disable-model-invocation: true
|
||||
---
|
||||
# Prepare Release
|
||||
|
||||
## Prerequisites: GitHub CLI
|
||||
|
||||
This workflow uses `gh` to fetch releases, compare branches, and draft release notes via the GitHub API. **Follow the check-github-cli skill** first (ensure `gh auth status` succeeds; if not, guide the user to install/configure `gh` and do not proceed). The account needs read access to the repo and, if you publish or draft releases, appropriate write access.
|
||||
|
||||
## Overview
|
||||
|
||||
Prepare the next release of the application.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Get the next release tag name
|
||||
|
||||
- Fetch the latest release from GitHub: `gh release list --limit 1` (or `gh release view` for the latest). Retrieve its tag name (e.g. `v1.2.3`).
|
||||
- **If the user did not specify which version bump to use:** Compute the next **minor** version per [semantic versioning](https://semver.org) (e.g. `v1.2.3` → `v1.3.0`).
|
||||
- **If the user specified major or patch:** Compute the next **major** (e.g. `v2.0.0`) or **patch** (e.g. `v1.2.4`) version accordingly.
|
||||
- Use this tag (e.g. `v1.3.0`) as the release tag for all following steps.
|
||||
|
||||
### 2. Update `./docs/ENVS.md` and `./docs/DEPRECATED_ENVS.md`
|
||||
|
||||
- In both files, replace every placeholder that contains the text "upcoming" with the next release tag followed by a "+". Examples:
|
||||
- `"upcoming"` → `"v1.3.0+"`
|
||||
- `"<upcoming>"` → `"v1.3.0+"`
|
||||
- You can use search-and-replace in the editor or a script (e.g. `sed -i '' 's/upcoming/v1.3.0+/g' ./docs/ENVS.md` and similarly for `DEPRECATED_ENVS.md`; adjust for `<upcoming>` if present). Ensure all such placeholders are updated.
|
||||
|
||||
### 3. Create release notes
|
||||
|
||||
Perform the following sub-steps **in order**.
|
||||
|
||||
- **Reference files:** Use `./RELEASE_NOTES.md` as the template and, for format inspiration, this [example release](https://github.com/blockscout/frontend/releases/tag/v2.3.0).
|
||||
- **Get release notes draft:** Use the GitHub API to generate draft release notes with main as the target (e.g. `gh api repos/OWNER/REPO/releases/generate-notes -f tag_name=<next-tag> -f target_commitish=main -f previous_tag_name=<latest-release-tag>`). Parse the response to get the list of pull request **numbers** and new contributors. Keep this list; every PR in it must appear in the final notes.
|
||||
- **Fetch and store PR data (labels and descriptions):** Before editing the release notes file, fetch labels and body for all PRs from the draft **once** and save them to a temporary file so later steps do not hit the GitHub API repeatedly. Use the script that rate-limits requests (authenticated API limit is 5000 requests/hour; the script adds a delay between calls).
|
||||
- From the **repository root**, run: `node .cursor/skills/prepare-release/fetch-release-prs.js <pr-number-1> <pr-number-2> ... --out release-prs-data.json` with every PR number from the release notes draft. Example: `node .cursor/skills/prepare-release/fetch-release-prs.js 2725 2726 2727 --out release-prs-data.json`.
|
||||
- The script writes JSON to `release-prs-data.json` in the repository root (format: `{ "prs": [ { "number", "title", "author", "url", "labels", "body" }, ... ] }`). Use this file as the **single source of truth** for labels and descriptions in the next two steps; do not call the GitHub API again when mapping sections or writing the ENV section.
|
||||
- **Copy and fill the notes file:** Copy `./RELEASE_NOTES.md` to a new file `./RELEASE_NOTES_<release-tag>.md` (e.g. `RELEASE_NOTES_v1.3.0.md`).
|
||||
- **Map PRs to sections:** For each section in the new file **except** "Changes in ENV variables", add the relevant pull requests. **Use only the data in `release-prs-data.json`** (labels, title, author, url) — do not call the GitHub API again. For each line use the format: `- <pull-request-title> by @<author> in <link-to-pull-request>`. Example: `- API documentation page by @tom2drum in https://github.com/blockscout/frontend/pull/2725`. Capitalize the first letter of the PR title if needed. Assign PRs to sections using each PR’s **labels** from the stored file and this mapping:
|
||||
|
||||
| Section | Labels |
|
||||
| ------------------------- | ------------------------------------------- |
|
||||
| New Features | feature, enhancement, client feature |
|
||||
| Bug Fixes | bug |
|
||||
| Performance Improvements | performance |
|
||||
| Dependencies updates | dependencies |
|
||||
| Design updates | design |
|
||||
|
||||
If a PR has no matching labels, try to categorize it based on its description (the **body** field in the `release-prs-data.json` file). If the section remains unclear, categorize it as "Other Changes." Never exclude a PR from the notes. The list of PRs in the release notes must match exactly the list from "Get release notes draft." Always double-check this.
|
||||
|
||||
- **"Changes in ENV variables" section:**
|
||||
- From `release-prs-data.json`, find all PRs whose **labels** include `"ENVs"` (or `ENVs`). Use their **body** field as the PR description.
|
||||
- For each of those PRs, strip the "Checklist for PR Author" part from the body if present. Then, summarize the changes to the ENV variables and rephrase them if necessary. If you are unable to determine the changes or are unsure, use the placeholder: "Cannot find any changes in ENVs in PR description."
|
||||
- Write the section in this form (grouped by PR number):
|
||||
```
|
||||
- <pull-request-number>:
|
||||
- <change-1>
|
||||
- <change-2>
|
||||
```
|
||||
- Examples:
|
||||
- #3005
|
||||
- Added `NEXT_PUBLIC_AD_BANNER_ENABLE_SPECIFY` to enable the Specify ad provider for users with a connected wallet.
|
||||
- Removed the `hype` option from the `NEXT_PUBLIC_AD_BANNER_PROVIDER` variable values.
|
||||
- #2968
|
||||
- Added `NEXT_PUBLIC_MEGA_ETH_SOCKET_URL_METRICS` to display information on the uptime dashboard page.
|
||||
|
||||
- **Final edits in the release notes file:**
|
||||
- Update "Full list of the ENV variables" and "Full Changelog" with the correct version tags/links.
|
||||
- Update the "New Contributors" section if the "Get release notes draft" response included new contributors.
|
||||
- Leave the "Compatibility" section content unchanged.
|
||||
@@ -0,0 +1,101 @@
|
||||
#!/usr/bin/env node
|
||||
/* eslint-disable no-console */
|
||||
/**
|
||||
* Fetches labels and description (body) for a list of pull requests via the GitHub API,
|
||||
* with rate limiting to avoid hitting API limits. Outputs JSON to a file for use when
|
||||
* preparing release notes (mapping PRs to sections and building the ENV variables section).
|
||||
*
|
||||
* Prerequisites: GitHub CLI (gh) installed and authenticated.
|
||||
*
|
||||
* Usage:
|
||||
* node fetch-release-prs.js <pr-number> [pr-number ...] [--out <path>]
|
||||
* echo "2725 2726" | xargs node fetch-release-prs.js --out release-prs-data.json
|
||||
*
|
||||
* Output JSON shape (written to --out or stdout):
|
||||
* { "prs": [ { "number", "title", "author", "url", "labels", "body" }, ... ] }
|
||||
*/
|
||||
|
||||
const { execSync } = require('child_process');
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
|
||||
const DELAY_MS = 400;
|
||||
|
||||
function getRepo() {
|
||||
try {
|
||||
return execSync('gh repo view --json nameWithOwner -q .nameWithOwner', {
|
||||
encoding: 'utf-8',
|
||||
}).trim();
|
||||
} catch {
|
||||
return 'blockscout/frontend';
|
||||
}
|
||||
}
|
||||
|
||||
function fetchPr(ownerRepo, number) {
|
||||
const [ owner, repo ] = ownerRepo.split('/');
|
||||
const out = execSync(
|
||||
`gh api repos/${ owner }/${ repo }/issues/${ number } --jq '{number, title, user: .user.login, labels: [.labels[].name], body}'`,
|
||||
{ encoding: 'utf-8', maxBuffer: 2 * 1024 * 1024 },
|
||||
);
|
||||
const data = JSON.parse(out);
|
||||
return {
|
||||
number: data.number,
|
||||
title: data.title,
|
||||
author: data.user,
|
||||
url: `https://github.com/${ ownerRepo }/pull/${ data.number }`,
|
||||
labels: data.labels || [],
|
||||
body: data.body || '',
|
||||
};
|
||||
}
|
||||
|
||||
function sleep(ms) {
|
||||
return new Promise((resolve) => setTimeout(resolve, ms));
|
||||
}
|
||||
|
||||
async function main() {
|
||||
const args = process.argv.slice(2);
|
||||
let outPath = null;
|
||||
const prNumbers = [];
|
||||
|
||||
for (let i = 0; i < args.length; i++) {
|
||||
if (args[i] === '--out' && args[i + 1]) {
|
||||
outPath = args[i + 1];
|
||||
i += 1;
|
||||
} else if (/^\d+$/.test(args[i])) {
|
||||
prNumbers.push(Number(args[i], 10));
|
||||
}
|
||||
}
|
||||
|
||||
if (prNumbers.length === 0) {
|
||||
console.error('Usage: node fetch-release-prs.js <pr-number> [pr-number ...] [--out <path>]');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const ownerRepo = getRepo();
|
||||
const prs = [];
|
||||
|
||||
for (let i = 0; i < prNumbers.length; i++) {
|
||||
const num = prNumbers[i];
|
||||
try {
|
||||
prs.push(fetchPr(ownerRepo, num));
|
||||
if (i < prNumbers.length - 1) {
|
||||
await sleep(DELAY_MS);
|
||||
}
|
||||
} catch (err) {
|
||||
console.error(`Failed to fetch PR #${ num }:`, err.message);
|
||||
process.exit(1);
|
||||
}
|
||||
}
|
||||
|
||||
const result = { prs };
|
||||
const json = JSON.stringify(result, null, 2);
|
||||
|
||||
if (outPath) {
|
||||
fs.writeFileSync(outPath, json, 'utf-8');
|
||||
console.error(`Wrote ${ prs.length } PR(s) to ${ path.resolve(outPath) }`);
|
||||
} else {
|
||||
console.log(json);
|
||||
}
|
||||
}
|
||||
|
||||
main();
|
||||
+2
-1
@@ -66,4 +66,5 @@ yarn-error.log*
|
||||
# build outputs
|
||||
/tools/preset-sync/index.js
|
||||
/toolkit/package/dist
|
||||
license.json
|
||||
license.json
|
||||
release-prs-data.json
|
||||
|
||||
@@ -83,6 +83,7 @@
|
||||
"clstr",
|
||||
"coinzilla",
|
||||
"coinzillatag",
|
||||
"commitish",
|
||||
"Computor",
|
||||
"contentscript",
|
||||
"contractname",
|
||||
|
||||
Reference in New Issue
Block a user