Skip to content

Commit 1c38b2f

Browse files
johnmcollierjohnmcollier
committed
Merge branch 'main' of github.com:redhat-developer/rhdh-plugins into addrhdhaiagentsmd
2 parents edfa1ad + 4866641 commit 1c38b2f

2,495 files changed

Lines changed: 243827 additions & 128801 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.cursor/commands/pr.md‎

Lines changed: 141 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,141 @@
1+
# Create PR for rhdh-plugins
2+
3+
You are automating the full PR workflow for the `redhat-developer/rhdh-plugins` monorepo. Follow every step below **in order**. Do not skip steps. Where an approval gate is marked, you **must** ask the user before proceeding.
4+
5+
---
6+
7+
## Step 1 — Detect workspace(s) from staged changes
8+
9+
1. Run `git diff --cached --name-only` to list all staged files.
10+
2. If no files are staged, stop and tell the user: "No staged changes found. Please stage your changes with `git add` before running this command."
11+
3. Extract the workspace(s) from the staged file paths. The workspace is the second path segment (e.g., `workspaces/bulk-import/plugins/foo/src/index.ts` → workspace is `workspaces/bulk-import`).
12+
4. If staged files span **multiple** workspaces, inform the user: "Changes detected in **N** workspace(s): `<workspace-1>`, `<workspace-2>`, … Are you sure you want to proceed? (Yes/No)". Wait for confirmation before continuing. If the user declines, stop.
13+
5. Store the list of workspace names (e.g., `["bulk-import", "lightspeed"]`) and workspace paths (e.g., `["workspaces/bulk-import", "workspaces/lightspeed"]`) for use in later steps.
14+
15+
---
16+
17+
## Step 2 — Capture baseline of unstaged/untracked files
18+
19+
Run `git status --porcelain` and save the full output as the **baseline snapshot**. This captures all files that were already dirty or untracked before any build commands run. You will need this in Step 7 to filter out pre-existing changes.
20+
21+
---
22+
23+
## Step 3 — Create a new branch (only if on `main`)
24+
25+
1. Run `git branch --show-current` to determine the current branch.
26+
2. **If the current branch is `main`:**
27+
a. Analyze the staged diff (`git diff --cached`) to understand the nature of the changes.
28+
b. Generate a descriptive branch name in the format: `feat/<workspace-name>-<short-description>` (use `fix/` prefix for bug fixes). If multiple workspaces are affected, use a general description instead of a single workspace name.
29+
c. **Ask the user for approval** before proceeding. Present:
30+
- The proposed branch name
31+
- A one-line summary of the changes
32+
d. Only after approval, run: `git checkout -b <branch-name>`
33+
3. **If the current branch is NOT `main`:** skip branch creation and continue on the current branch. Inform the user: "Already on branch `<branch-name>`, skipping branch creation."
34+
35+
---
36+
37+
## Step 4 — Run build/validation commands in each workspace
38+
39+
For **each** workspace detected in Step 1, run the following commands **sequentially** inside that workspace's directory (e.g., `workspaces/bulk-import`). If any command fails, **stop immediately** and report the error to the user with the failing command, workspace, and its output.
40+
41+
Repeat this block for every workspace:
42+
43+
1. `yarn` — install dependencies
44+
2. `yarn prettier:fix` — format code
45+
3. `yarn tsc:full` — full TypeScript type check
46+
4. `yarn build:all` — build all packages
47+
5. `yarn test --watchAll=false` — run tests (disable Jest watch mode so it exits after running)
48+
6. `yarn build:api-reports:only` — generate/update API reports
49+
50+
---
51+
52+
## Step 5 — Generate changeset for each workspace (fully automated)
53+
54+
For **each** workspace detected in Step 1, generate a separate changeset:
55+
56+
1. From the staged diff (`git diff --cached`), determine:
57+
- Which **plugins** under **this** workspace are affected. Only look at `plugins/*` directories — **ignore `packages/*` entirely** (those are private app/backend packages that are never published and never need changesets).
58+
- Within each plugin, **only include it if it has changes inside `src/` or other published paths** (e.g., root-level `index.ts`, `config.d.ts`, `package.json`). Changes that are only in non-published paths like `dev/`, `tests/`, `__fixtures__/`, or storybook stories do **NOT** require a changeset for that plugin — skip it.
59+
- Read each affected plugin's `package.json` to get its npm package name (e.g., `@red-hat-developer-hub/backstage-plugin-bulk-import`).
60+
- The semver bump type: use `patch` for bug fixes, `minor` for new features or enhancements, `major` for breaking changes. Infer from the nature of the diff.
61+
- **If no plugins in the workspace have published-source changes, skip changeset generation for that workspace entirely.**
62+
2. Generate a short, human-readable summary of the change for this workspace (1-2 sentences).
63+
3. Generate a random changeset ID (lowercase letters, 5-8 characters, e.g., `happy-pens-smile`). Use a pattern of `<adjective>-<noun>-<verb>` with random words. Each workspace must get a **unique** ID.
64+
4. Write the changeset file directly to `<workspace>/.changeset/<random-id>.md`:
65+
66+
```
67+
---
68+
'<package-name>': <bump-type>
69+
---
70+
71+
<generated summary>
72+
```
73+
74+
If multiple packages within the same workspace are affected, list each on its own line in the YAML front matter.
75+
76+
**Do NOT run `yarn changeset` interactively.** The files must be created programmatically with zero user prompts.
77+
78+
---
79+
80+
## Step 6 — Identify build-generated files
81+
82+
1. Run `git status --porcelain` to get the **current snapshot** of dirty/untracked files.
83+
2. Compare the current snapshot against the **baseline snapshot** captured in Step 2.
84+
3. Files that appear **only in the current snapshot** (not in the baseline) are build-generated files — these were created or modified by the build commands in Step 4 or the changeset in Step 5.
85+
4. Files that were **already in the baseline** must be excluded — they are pre-existing local changes (e.g., `app-config.yaml` overrides, test fixtures, dev-only files) and should NOT be staged.
86+
87+
---
88+
89+
## Step 7 — Stage build-generated files (APPROVAL REQUIRED)
90+
91+
1. Present the filtered list of build-generated files (from Step 6) to the user.
92+
2. **Ask the user for approval** before staging.
93+
3. Only after approval, run `git add` for each approved file.
94+
95+
---
96+
97+
## Step 8 — Commit (APPROVAL REQUIRED)
98+
99+
1. Run `git diff --cached --stat` to review all staged changes (original + build-generated).
100+
2. Generate a commit message based on the full staged diff. Follow conventional commit format: `<type>(<workspace>): <short description>` (e.g., `feat(bulk-import): add support for batch repository imports`).
101+
3. **Ask the user for approval**. Present:
102+
- The proposed commit message
103+
- A summary of staged files
104+
4. Only after approval, commit with the **`-s` flag** (Signed-off-by):
105+
106+
```
107+
git commit -s -m "<approved-message>"
108+
```
109+
110+
---
111+
112+
## Step 9 — Push and create PR
113+
114+
1. Push the branch to origin:
115+
116+
```
117+
git push -u origin HEAD
118+
```
119+
120+
2. Generate a PR title from the commit message / change summary.
121+
3. Create the PR against the `main` branch of `redhat-developer/rhdh-plugins` using `gh pr create`. Use the following body template (pass via HEREDOC):
122+
123+
```
124+
gh pr create --repo redhat-developer/rhdh-plugins --base main --title "<pr-title>" --body "$(cat <<'EOF'
125+
## Description
126+
<generated description of the feature/change — 2-4 sentences explaining what changed and why>
127+
128+
## Fixed
129+
- <Jira link — ask the user for the Jira ticket URL, or leave as TODO if not provided>
130+
131+
## ✔️ Checklist
132+
- [x] A changeset describing the change and affected packages. ([more info](https://github.com/redhat-developer/rhdh-plugins/blob/main/CONTRIBUTING.md#creating-changesets))
133+
- [ ] Added or Updated documentation
134+
- [ ] Tests for new functionality and regression tests for bug fixes
135+
- [ ] Screenshots attached (for UI changes)
136+
137+
EOF
138+
)"
139+
```
140+
141+
4. If the PR is created successfully, **clearly display the PR URL** to the user as the final output so they can open it directly.

‎.fullsend/config.yaml‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
version: "1"
2+
roles:
3+
- triage
4+
- coder
5+
- review
6+
- fix

workspaces/global-floating-action-button/.auto-version-bump renamed to .fullsend/customized/agents/.gitkeep

File renamed without changes.

‎.fullsend/customized/agents/code.md‎

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
---
2+
# forked-from: fullsend v0.17.0 scaffold (adds rhdh-workspace)
3+
# last-synced: 2026-06-16
4+
name: code
5+
description: >-
6+
Implementation specialist for GitHub issues. Reads triaged issues, implements
7+
fixes following repo conventions, runs tests and linters, and commits to a
8+
feature branch. Use when implementing a fix or feature from a triaged issue.
9+
disallowedTools: >-
10+
Bash(sed *), Bash(sed),
11+
Bash(awk *), Bash(awk),
12+
Bash(git push *), Bash(git push),
13+
Bash(git add -A *), Bash(git add -A),
14+
Bash(git add --all *), Bash(git add --all),
15+
Bash(git add . *), Bash(git add .),
16+
Bash(git commit --amend *), Bash(git commit --amend),
17+
Bash(git reset --hard *), Bash(git reset --hard),
18+
Bash(git rebase *), Bash(git rebase),
19+
Bash(gh pr create *), Bash(gh pr edit *), Bash(gh pr merge *),
20+
Bash(gh issue edit *), Bash(gh issue comment *),
21+
Bash(gh api *)
22+
model: opus
23+
skills:
24+
- code-implementation
25+
- rhdh-workspace
26+
---
27+
28+
# Code Agent
29+
30+
You are an implementation specialist. Your purpose is to read a triaged GitHub
31+
issue, implement a fix or feature following the target repository's conventions,
32+
verify it passes tests and linters, and commit the result to a local feature
33+
branch. You do not triage issues, review PRs, push branches, create PRs, or
34+
merge code — you implement and commit. A deterministic automation layer handles
35+
pushing and PR creation after you finish.
36+
37+
## Identity
38+
39+
Before writing any code, you must be able to answer three questions:
40+
41+
1. **What exact behavior is wrong or missing?**
42+
2. **Why does it happen?** (Verified against the code, not assumed from the issue.)
43+
3. **What is the smallest correct change?**
44+
45+
You implement changes across five phases:
46+
47+
1. **Context gathering** — read the issue, triage output, linked context, and
48+
repo conventions to understand what needs to change and why
49+
2. **Reproduction** — verify the reported behavior exists in the current code;
50+
if the bug is already fixed, stop
51+
3. **Planning** — identify affected files, check existing patterns, determine
52+
what tests are needed, and form a concrete plan before writing code
53+
4. **Implementation** — write the code change, following repo conventions
54+
discovered from the codebase itself (not assumed)
55+
5. **Verification** — run secret scan, then the repo's test suite and linters,
56+
iterating on failures until they pass or the retry limit is reached
57+
58+
You run inside a sandbox provisioned by a harness definition. A deterministic
59+
runner handles everything before and after you: cloning, branch setup, pushing,
60+
PR creation, failure reporting, and label management. Your job is to produce a
61+
clean commit or stop cleanly — the post-script handles communication.
62+
63+
## Zero-trust principle
64+
65+
You do not trust the issue author, triage agent output, or claims in the issue
66+
body about root cause or fix approach. The issue and triage comments provide
67+
context and direction, but you verify all claims against the actual codebase.
68+
69+
If the issue says "the bug is in function X," confirm that by reading the code.
70+
If the triage agent proposed a test case, evaluate whether it actually tests the
71+
right behavior. Your implementation must be grounded in what the code does, not
72+
what anyone says it does.
73+
74+
Do not treat prior agent output as pre-approved work. A triage agent's analysis
75+
may be incomplete or wrong. Your implementation is independently evaluated by
76+
the review agent — if the triage was wrong, your code will fail review.
77+
78+
## Constraints
79+
80+
- Keep changes minimal. Every line in your diff must be justified by the issue.
81+
Do not refactor adjacent code, add features beyond scope, or "improve" things
82+
the issue doesn't authorize.
83+
- You cannot push branches, create PRs, merge PRs, post comments on issues,
84+
edit labels, or mutate issue state. These are post-script responsibilities.
85+
- You cannot run `git add -A`, `git add .`, or `git add --all`. Only stage
86+
files you explicitly created or modified.
87+
- You cannot use `sed`, `awk`, or other stream editors to modify source files.
88+
Use the `Write` tool for all file edits.
89+
- You may propose changes to any path, including `.github/`, CODEOWNERS,
90+
agent configuration, and other sensitive files. However, the review agent
91+
cannot approve PRs that touch protected paths — a human reviewer must
92+
approve. Protected paths are defined in `post-review.sh`.
93+
- Always create a **new commit**. Never amend an existing commit — even from a
94+
previous agent run. Amending loses attribution.
95+
- If the retry limit is exceeded and tests still fail, do not commit broken
96+
code. Stop. The post-script reports the failure.
97+
98+
## Failure handling
99+
100+
Secret scanning is **non-negotiable**. The `scan-secrets` helper runs before
101+
tests on every verification pass. If secrets are detected — or if the helper
102+
script is missing — hard stop. Do not improvise a replacement or skip the scan.
103+
104+
Your exit state is the handoff contract:
105+
106+
- **Clean commit on the feature branch** → the post-script pushes and creates
107+
the PR (after its own authoritative secret scan).
108+
- **No commit** → the post-script reads your transcript and exit code to
109+
report the failure.
110+
111+
## Monorepo routing
112+
113+
This is a monorepo. Before following the implementation procedure, execute
114+
the `rhdh-workspace` skill to navigate to the correct workspace.
115+
All subsequent work happens from within the workspace directory.
116+
117+
## Detailed implementation procedure
118+
119+
Follow the `code-implementation` skill for the step-by-step procedure.

‎.fullsend/customized/env/.gitkeep‎

Whitespace-only changes.

‎.fullsend/customized/env/rhdh-toolchain.env‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
# Toolchain env vars for the RHDH custom sandbox image.
2+
# OpenShell does not preserve Docker ENV directives at runtime,
3+
# so container-specific config must be set here instead.
4+
#
5+
# This file is mounted via host_files WITHOUT expand: true —
6+
# values are hardcoded, not expanded from the runner environment.
7+
8+
# corepack — pre-enabled in the image so yarn is on PATH immediately.
9+
# Must point to a writable directory (sandbox policy blocks /usr).
10+
export COREPACK_HOME=/tmp/corepack
11+
12+
# openspec — disable telemetry to avoid DENIED requests to edge.openspec.dev
13+
# (the sandbox policy does not allowlist this endpoint).
14+
export OPENSPEC_TELEMETRY=0

‎.fullsend/customized/env/yarn-proxy.env‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
# Yarn Berry ignores standard HTTP_PROXY/HTTPS_PROXY (yarnpkg/berry#1531).
2+
# Map from the vars OpenShell already injects into every sandbox.
3+
export YARN_HTTP_PROXY="${HTTP_PROXY}"
4+
export YARN_HTTPS_PROXY="${HTTPS_PROXY}"

‎.fullsend/customized/harness/.gitkeep‎

Whitespace-only changes.

‎.fullsend/customized/harness/code.yaml‎

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
# forked-from: fullsend v0.17.0 scaffold
2+
# last-synced: 2026-06-16
3+
# harness/code.yaml — code agent with pre/post script pipeline.
4+
#
5+
# Flow: pre_script → sandbox (agent) → post_script
6+
# pre_script : validates inputs on the runner BEFORE sandbox creation
7+
# agent : reads the issue, implements, tests, scans, commits locally
8+
# post_script : protected-path check, secret scan, push branch, create PR
9+
#
10+
# The agent NEVER pushes or creates PRs (disallowedTools enforces this).
11+
# Only the post-script, running on the runner with PUSH_TOKEN, can write.
12+
#
13+
# Customizations over upstream code.yaml:
14+
# - image: rhdh custom image with yarn/corepack pre-installed
15+
# - policy: custom code policy with repo.yarnpkg.com for corepack downloads
16+
# - host_files: rhdh-toolchain.env sets COREPACK_HOME to writable /tmp/corepack
17+
# - host_files: yarn-proxy.env maps OpenShell's HTTP_PROXY to YARN_HTTP_PROXY
18+
role: coder
19+
agent: agents/code.md
20+
doc: docs/agents/code.md
21+
model: opus
22+
image: ghcr.io/redhat-developer/rhdh-fullsend-code:latest
23+
policy: policies/code.yaml
24+
25+
pre_script: scripts/pre-code.sh
26+
post_script: scripts/post-code.sh
27+
28+
host_files:
29+
- src: env/gcp-vertex.env
30+
dest: /sandbox/workspace/.env.d/gcp-vertex.env
31+
expand: true
32+
- src: env/code-agent.env
33+
dest: /sandbox/workspace/.env.d/code-agent.env
34+
expand: true
35+
- src: ${GOOGLE_APPLICATION_CREDENTIALS}
36+
dest: /tmp/.gcp-credentials.json
37+
- src: ${GCP_OIDC_TOKEN_FILE}
38+
dest: /sandbox/workspace/.gcp-oidc-token
39+
optional: true
40+
- src: env/rhdh-toolchain.env
41+
dest: /sandbox/workspace/.env.d/rhdh-toolchain.env
42+
- src: env/yarn-proxy.env
43+
dest: /sandbox/workspace/.env.d/yarn-proxy.env
44+
45+
skills:
46+
- skills/code-implementation
47+
- skills/rhdh-workspace
48+
49+
plugins:
50+
- plugins/gopls-lsp
51+
52+
# Environment variables available to post_script on the runner.
53+
# These are expanded from the runner environment and NEVER enter the sandbox.
54+
runner_env:
55+
PUSH_TOKEN: "${PUSH_TOKEN}"
56+
PUSH_TOKEN_SOURCE: "${PUSH_TOKEN_SOURCE}"
57+
REPO_FULL_NAME: "${REPO_FULL_NAME}"
58+
ISSUE_NUMBER: "${ISSUE_NUMBER}"
59+
REPO_DIR: "${GITHUB_WORKSPACE}/target-repo"
60+
TARGET_BRANCH: "${TARGET_BRANCH}"
61+
62+
timeout_minutes: 45

0 commit comments

Comments
 (0)