CNTRLPLANE-3674: Add generic jira-agent step registry for cross-team reuse#80927
CNTRLPLANE-3674: Add generic jira-agent step registry for cross-team reuse#80927bryan-cox wants to merge 7 commits into
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@bryan-cox: This pull request references CNTRLPLANE-3674 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR introduces a reusable, parameterized ChangesJira agent generalization and HyperShift adoption
Sequence Diagram(s)sequenceDiagram
participant HyperShift as HyperShift Workflow
participant Setup as jira-agent-setup
participant Process as jira-agent-process
participant Claude as Claude Code CLI
participant GitHub as GitHub API
participant Jira as Jira Cloud
participant Report as jira-agent-report
participant Slack as Slack
HyperShift->>Setup: pre phase
Setup->>Setup: verify Claude CLI & Vertex/GCP auth
Setup-->>HyperShift: setup complete
HyperShift->>Process: test phase
Process->>Jira: search issues by JQL or key
loop for each matched issue
Process->>Claude: Phase 1: solve with fork context
Process->>Claude: Phase 2: review code (lang/profile)
Process->>Claude: Phase 3: fix (refresh fork token)
Process->>GitHub: push branch
Process->>Claude: Phase 4: draft PR (refresh tokens)
Process->>GitHub: create PR to upstream
Process->>Jira: transition status (project-key derived)
Process->>Jira: assign user (displayName regex)
Process->>Jira: add agent-processed label
Process->>Slack: notify with emoji and reviewers
Process->>Process: record tokens and outcome
end
HyperShift->>Report: post phase
Report->>Report: aggregate token counts by model
Report->>Report: render HTML with Jira links
Report-->>HyperShift: report complete
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bryan-cox The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
@bryan-cox, Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@ci-operator/step-registry/jira-agent/process/jira-agent-process-commands.sh`:
- Around line 723-726: When Phase 4 (PR creation) fails as indicated by the
PR_EXIT_CODE check in the else block, the script currently continues to mark the
Jira issue as processed by adding the agent-processed label and recording a
SUCCESS status. This prevents the issue from being retried in future runs. After
the else block that handles the PR creation failure case (where PR_URL is set to
empty), add logic to skip the Jira issue update step that adds the
agent-processed label and records the SUCCESS status, ensuring that failed PR
creations do not permanently suppress retries. Apply the same fix to all similar
failure handling blocks referenced at lines 763-826 where Phase 4 failures
occur.
- Around line 242-247: The transition_issue function's curl command currently
returns success regardless of the HTTP response status from Jira. Modify the
curl command to capture the HTTP status code using the -w option and store it in
a variable, then add a conditional check to verify the status code is in the 2xx
success range before returning 0; if the status indicates an error (4xx or 5xx),
return a non-zero exit code instead to properly reflect the failure to the
caller.
- Around line 6-18: The validation loop that checks for required environment
variables runs before the override handling block, causing the script to always
require JIRA_AGENT_JQL even when executing in single-issue mode with
JIRA_AGENT_ISSUE_KEY. Move the override handling block (the if statement
checking MULTISTAGE_PARAM_OVERRIDE_JIRA_AGENT_ISSUE_KEY) to execute before the
validation loop, so that JIRA_AGENT_ISSUE_KEY can be properly set via override
before the required variables are checked. This allows single-issue mode to work
when only JIRA_AGENT_ISSUE_KEY is provided through overrides, making
JIRA_AGENT_JQL optional in that scenario.
In `@ci-operator/step-registry/jira-agent/README.md`:
- Around line 66-75: The README documentation lists incorrect Vault secret key
names that do not match the keys actually consumed by the process script. Update
the secret keys listed in the documented Vault secret section to use the correct
key names: replace `jira-token` with `jira-pat`, replace `jira-user` with
`jira-email`, replace `slack-webhook` with `slack-webhook-url`, replace
`github-app-id` with `app-id`, and replace `github-app-private-key` with
`private-key`. This ensures teams setting up Vault secrets according to the
README will use the correct key names expected by the process script.
In `@ci-operator/step-registry/jira-agent/report/jira-agent-report-commands.sh`:
- Around line 58-62: The sum_costs helper is interpolating untrusted values
directly into the awk program, which allows code injection instead of a plain
numeric sum. Update sum_costs to validate or coerce the inputs before use, and
pass the values to awk in a safe way (for example via awk variables or another
numeric-only approach) so only arithmetic is performed. Keep the fix localized
to sum_costs in jira-agent-report-commands.sh and preserve the existing fallback
behavior.
In `@ci-operator/step-registry/jira-agent/setup/jira-agent-setup-commands.sh`:
- Around line 6-9: Add an explicit Vertex AI credentials preflight in
jira-agent-setup-commands.sh instead of only checking Claude Code CLI
availability. In the setup flow around the existing claude --version check,
validate that GOOGLE_APPLICATION_CREDENTIALS is set and points to a readable
credentials file (or otherwise confirm ADC is usable), and fail fast with a
clear error message if it is missing or inaccessible. Keep the existing CLI
verification, but extend the setup script so authentication issues are detected
during setup rather than later.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 0ddea49f-bb00-4f8e-86b7-48196c29e9b2
📒 Files selected for processing (17)
ci-operator/step-registry/hypershift/jira-agent/hypershift-jira-agent-workflow.yamlci-operator/step-registry/jira-agent/OWNERSci-operator/step-registry/jira-agent/README.mdci-operator/step-registry/jira-agent/jira-agent-workflow.metadata.jsonci-operator/step-registry/jira-agent/jira-agent-workflow.yamlci-operator/step-registry/jira-agent/process/OWNERSci-operator/step-registry/jira-agent/process/jira-agent-process-commands.shci-operator/step-registry/jira-agent/process/jira-agent-process-ref.metadata.jsonci-operator/step-registry/jira-agent/process/jira-agent-process-ref.yamlci-operator/step-registry/jira-agent/report/OWNERSci-operator/step-registry/jira-agent/report/jira-agent-report-commands.shci-operator/step-registry/jira-agent/report/jira-agent-report-ref.metadata.jsonci-operator/step-registry/jira-agent/report/jira-agent-report-ref.yamlci-operator/step-registry/jira-agent/setup/OWNERSci-operator/step-registry/jira-agent/setup/jira-agent-setup-commands.shci-operator/step-registry/jira-agent/setup/jira-agent-setup-ref.metadata.jsonci-operator/step-registry/jira-agent/setup/jira-agent-setup-ref.yaml
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@ci-operator/step-registry/jira-agent/process/jira-agent-process-commands.sh`:
- Line 444: Relying on prompt text to prevent Claude from accessing GitHub
tokens via git credential helpers is ineffective. Instead of trying to restrict
Claude's commands through instructions, remove or unset the credential helper
before invoking Claude (in the FORK_CONTEXT variable and similar messages at
lines 519, 584, 602, 662, and 694), allow Claude to create commits locally only,
then have the wrapper script perform authenticated git push and PR operations
after Claude execution completes using a temporary credential helper. This moves
the security boundary outside Claude's execution context and aligns with coding
guidelines that protect sensitive credentials from being exposed in
step-registry command scripts.
- Around line 578-587: The issue is that GITHUB_TOKEN_FORK is assigned directly
from the generate_github_token function call before validating the result, so if
the function fails or returns null, the previous token value is lost even though
the code claims to be "continuing with previous token". To fix this, create a
temporary variable to capture the output of generate_github_token (for both
GITHUB_TOKEN_FORK and GITHUB_TOKEN_UPSTREAM as mentioned), then only assign the
result to the actual token variable inside the conditional block if the
temporary variable contains a valid value. This ensures the previous token is
preserved when the refresh fails.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: d8a23e36-07a9-461a-9292-c1376f4fb60e
📒 Files selected for processing (9)
ci-operator/step-registry/hypershift/jira-agent/README.mdci-operator/step-registry/hypershift/jira-agent/process/OWNERSci-operator/step-registry/hypershift/jira-agent/process/hypershift-jira-agent-process-ref.yamlci-operator/step-registry/hypershift/jira-agent/report/OWNERSci-operator/step-registry/hypershift/jira-agent/report/hypershift-jira-agent-report-ref.yamlci-operator/step-registry/hypershift/jira-agent/setup/OWNERSci-operator/step-registry/jira-agent/README.mdci-operator/step-registry/jira-agent/process/jira-agent-process-commands.shci-operator/step-registry/jira-agent/report/jira-agent-report-commands.sh
💤 Files with no reviewable changes (6)
- ci-operator/step-registry/hypershift/jira-agent/process/hypershift-jira-agent-process-ref.yaml
- ci-operator/step-registry/hypershift/jira-agent/report/OWNERS
- ci-operator/step-registry/hypershift/jira-agent/process/OWNERS
- ci-operator/step-registry/hypershift/jira-agent/README.md
- ci-operator/step-registry/hypershift/jira-agent/setup/OWNERS
- ci-operator/step-registry/hypershift/jira-agent/report/hypershift-jira-agent-report-ref.yaml
✅ Files skipped from review due to trivial changes (1)
- ci-operator/step-registry/jira-agent/README.md
|
/pj-rehearse periodic-ci-openshift-hypershift-main-periodic-jira-agent |
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse periodic-ci-openshift-hypershift-main-periodic-jira-agent |
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@bryan-cox, |
|
@bryan-cox, Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
…reuse Extract the HyperShift-specific jira-agent prow job into a generic, parameterized step registry that any team can reuse by creating a thin wrapper workflow with their own env vars and credentials. New generic steps at ci-operator/step-registry/jira-agent/: - setup: Verifies Claude Code CLI with Vertex AI auth - process: 4-phase pipeline (solve, review, fix, PR) with 15+ configurable env vars replacing all hardcoded HyperShift values - report: HTML report with token usage and cost breakdown The existing hypershift/jira-agent workflow is converted to a thin wrapper that references the generic steps and sets HyperShift-specific configuration. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…vars - Move env block inside workflow steps (workflows don't support top-level env) - Regenerate metadata JSON files with make registry-metadata - Remove unused UPSTREAM_ORG and UPSTREAM_REPO_NAME variables (shellcheck SC2034) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix credential key names in README (jira-pat, jira-email, app-id, private-key, slack-webhook-url, gh-to-slack-ids) - Clarify that credential secret name requires forking ref YAMLs - Add git config commands to security warnings in all 4 Claude prompts - Add set +x tracing guards around all credential operations (GitHub token gen, Jira auth, token refreshes) - Change exit 0 to exit 1 on missing credentials with state file - Delete orphaned hypershift/jira-agent/setup|process|report directories - Fix unquoted $MODEL_FILES in report script (use bash array) - Improve token refresh error messages to note stale token fallback - Add trust boundary comment for eval'd env vars Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Move Gangway override before validation so JIRA_AGENT_JQL is optional when JIRA_AGENT_ISSUE_KEY is provided (fixes single-issue mode) - Check Jira transition POST HTTP status before returning success - Don't mark issues as agent-processed when PR creation fails - Use temp variable pattern for token refresh to preserve previous token on failure instead of overwriting - Fix awk code injection in sum_costs by using -v variable assignment - Add Vertex AI credentials preflight check in setup step Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The CI pod doesn't have GitHub's ED25519 host key in known_hosts, causing claude plugin install to fail with strict host key checking. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
bryan-cox
force-pushed
the
CNTRLPLANE-3674-generic-jira-agent
branch
from
ff34e85 to
535e538
Compare
|
/pj-rehearse periodic-ci-openshift-hypershift-main-periodic-jira-agent |
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@ci-operator/step-registry/jira-agent/setup/jira-agent-setup-ref.yaml`:
- Around line 31-34: The documentation comment on Line 34 states that teams can
override the credential secret name in their wrapper workflow, but this
contradicts the hardcoded credentials.name reference on Line 28, which does not
actually allow such overrides. Update the documentation comment to accurately
reflect the current implementation by either removing the misleading statement
about credential secret name overrides, or clarifying the exact limitations and
how teams should actually configure their wrapper workflows when using this ref.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 0213be8c-e1de-4b18-8582-6d887ea4c0f5
📒 Files selected for processing (23)
ci-operator/step-registry/hypershift/jira-agent/README.mdci-operator/step-registry/hypershift/jira-agent/hypershift-jira-agent-workflow.yamlci-operator/step-registry/hypershift/jira-agent/process/OWNERSci-operator/step-registry/hypershift/jira-agent/process/hypershift-jira-agent-process-ref.yamlci-operator/step-registry/hypershift/jira-agent/report/OWNERSci-operator/step-registry/hypershift/jira-agent/report/hypershift-jira-agent-report-ref.yamlci-operator/step-registry/hypershift/jira-agent/setup/OWNERSci-operator/step-registry/jira-agent/OWNERSci-operator/step-registry/jira-agent/README.mdci-operator/step-registry/jira-agent/jira-agent-workflow.metadata.jsonci-operator/step-registry/jira-agent/jira-agent-workflow.yamlci-operator/step-registry/jira-agent/process/OWNERSci-operator/step-registry/jira-agent/process/jira-agent-process-commands.shci-operator/step-registry/jira-agent/process/jira-agent-process-ref.metadata.jsonci-operator/step-registry/jira-agent/process/jira-agent-process-ref.yamlci-operator/step-registry/jira-agent/report/OWNERSci-operator/step-registry/jira-agent/report/jira-agent-report-commands.shci-operator/step-registry/jira-agent/report/jira-agent-report-ref.metadata.jsonci-operator/step-registry/jira-agent/report/jira-agent-report-ref.yamlci-operator/step-registry/jira-agent/setup/OWNERSci-operator/step-registry/jira-agent/setup/jira-agent-setup-commands.shci-operator/step-registry/jira-agent/setup/jira-agent-setup-ref.metadata.jsonci-operator/step-registry/jira-agent/setup/jira-agent-setup-ref.yaml
💤 Files with no reviewable changes (6)
- ci-operator/step-registry/hypershift/jira-agent/report/hypershift-jira-agent-report-ref.yaml
- ci-operator/step-registry/hypershift/jira-agent/process/hypershift-jira-agent-process-ref.yaml
- ci-operator/step-registry/hypershift/jira-agent/README.md
- ci-operator/step-registry/hypershift/jira-agent/process/OWNERS
- ci-operator/step-registry/hypershift/jira-agent/setup/OWNERS
- ci-operator/step-registry/hypershift/jira-agent/report/OWNERS
✅ Files skipped from review due to trivial changes (8)
- ci-operator/step-registry/jira-agent/setup/jira-agent-setup-ref.metadata.json
- ci-operator/step-registry/jira-agent/process/OWNERS
- ci-operator/step-registry/jira-agent/jira-agent-workflow.metadata.json
- ci-operator/step-registry/jira-agent/process/jira-agent-process-ref.metadata.json
- ci-operator/step-registry/jira-agent/report/OWNERS
- ci-operator/step-registry/jira-agent/setup/OWNERS
- ci-operator/step-registry/jira-agent/README.md
- ci-operator/step-registry/jira-agent/report/jira-agent-report-ref.metadata.json
🚧 Files skipped from review as they are similar to previous changes (8)
- ci-operator/step-registry/jira-agent/jira-agent-workflow.yaml
- ci-operator/step-registry/jira-agent/report/jira-agent-report-ref.yaml
- ci-operator/step-registry/hypershift/jira-agent/hypershift-jira-agent-workflow.yaml
- ci-operator/step-registry/jira-agent/OWNERS
- ci-operator/step-registry/jira-agent/process/jira-agent-process-ref.yaml
- ci-operator/step-registry/jira-agent/setup/jira-agent-setup-commands.sh
- ci-operator/step-registry/jira-agent/report/jira-agent-report-commands.sh
- ci-operator/step-registry/jira-agent/process/jira-agent-process-commands.sh
| Generic setup step for the Jira agent periodic job. | ||
| Verifies Claude Code CLI is available. | ||
| Uses Vertex AI for Claude authentication via GCP service account. | ||
| Teams should override the credential secret name in their wrapper workflow. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Correct the credential override guidance.
Line 34 says wrapper workflows can override the secret name, but this ref hardcodes credentials.name (Line 28), so that instruction is misleading and can cause onboarding failures.
Suggested doc fix
- Teams should override the credential secret name in their wrapper workflow.
+ Teams onboarding this workflow should create team-specific ref YAMLs (or use a shared credential name), because the credential secret name is defined in the ref.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Generic setup step for the Jira agent periodic job. | |
| Verifies Claude Code CLI is available. | |
| Uses Vertex AI for Claude authentication via GCP service account. | |
| Teams should override the credential secret name in their wrapper workflow. | |
| Generic setup step for the Jira agent periodic job. | |
| Verifies Claude Code CLI is available. | |
| Uses Vertex AI for Claude authentication via GCP service account. | |
| Teams onboarding this workflow should create team-specific ref YAMLs (or use a shared credential name), because the credential secret name is defined in the ref. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@ci-operator/step-registry/jira-agent/setup/jira-agent-setup-ref.yaml` around
lines 31 - 34, The documentation comment on Line 34 states that teams can
override the credential secret name in their wrapper workflow, but this
contradicts the hardcoded credentials.name reference on Line 28, which does not
actually allow such overrides. Update the documentation comment to accurately
reflect the current implementation by either removing the misleading statement
about credential secret name overrides, or clarifying the exact limitations and
how teams should actually configure their wrapper workflows when using this ref.
claude plugin install clones via SSH as a different user, so ssh-keyscan for the script user doesn't help. Use git insteadOf to rewrite git@github.com: URLs to HTTPS globally. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
/pj-rehearse periodic-ci-openshift-hypershift-main-periodic-jira-agent |
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
The YAML | block scalar for JIRA_AGENT_EXTRA_PLUGIN_COMMANDS adds a trailing newline. The piped while loop ran in a subshell, and when [ -n "" ] && eval "$cmd" evaluated to exit 1 on the empty trailing line, pipefail propagated the non-zero status and set -e killed the script immediately after plugin installation with no output. Fix: - Use heredoc (<<<) instead of pipe to avoid subshell - Use if/fi instead of && so empty lines don't produce exit 1 - Remove redundant ssh-keyscan (insteadOf config alone suffices) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
/pj-rehearse |
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse periodic-ci-openshift-hypershift-main-periodic-jira-agent |
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
/pj-rehearse periodic-ci-openshift-hypershift-main-periodic-jira-agent |
|
@bryan-cox: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@bryan-cox: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
2 participants
Summary
jira-agentstep registry atci-operator/step-registry/jira-agent/that any team can reuse by creating a thin wrapper workflowJIRA_AGENT_FORK_REPO,JIRA_AGENT_UPSTREAM_REPO,JIRA_AGENT_JQL,JIRA_AGENT_TARGET_STATUS, etc.)hypershift/jira-agentworkflow to a thin wrapper that references the generic steps with HyperShift-specific configurationDetails
The generic step registry supports:
New env vars for team customization:
JIRA_AGENT_FORK_REPOJIRA_AGENT_UPSTREAM_REPOJIRA_AGENT_JQLJIRA_AGENT_TARGET_STATUSJIRA_AGENT_ASSIGNEEJIRA_AGENT_EXTRA_PLUGIN_COMMANDSJIRA_AGENT_TOOL_SETUP_SCRIPTJIRA_AGENT_REVIEW_LANGUAGE/JIRA_AGENT_REVIEW_PROFILEThe HyperShift wrapper preserves full backward compatibility — the periodic job config (
workflow: hypershift-jira-agent) is unchanged.Test plan
make validate-step-registrypassesmake registry-metadatagenerates correct metadataperiodic-jira-agentjob config still referenceshypershift-jira-agentworkflow🤖 Generated with Claude Code
Summary by CodeRabbit
This PR refactors OpenShift CI’s Jira-powered Claude Code automation into a reusable, parameterized step registry and updates the HyperShift Jira agent workflow to become a thin wrapper around those shared steps—reducing hardcoded HyperShift-specific logic and enabling cross-team adoption.
What changed (practical impact):
ci-operator/step-registry/jira-agent/that standardizes how teams:ci-operator/step-registry/hypershift/jira-agent/hypershift-jira-agent-workflow.yamlto delegate itspre,test, andpostphases to the new generic step refs (jira-agent-setup,jira-agent-process,jira-agent-report) while supplying HyperShift-specific configuration via environment variables.workflow: hypershift-jira-agent) remains unchanged.Configurability for wrapper workflows:
The generic steps are designed to be controlled entirely by wrapper-provided environment variables, including (among others):
JIRA_AGENT_FORK_REPO,JIRA_AGENT_UPSTREAM_REPO,JIRA_AGENT_JQLJIRA_AGENT_TARGET_STATUS,JIRA_AGENT_ASSIGNEEJIRA_AGENT_EXTRA_PLUGIN_COMMANDS,JIRA_AGENT_TOOL_SETUP_SCRIPTJIRA_AGENT_REVIEW_LANGUAGE,JIRA_AGENT_REVIEW_PROFILEAdditional repo/infrastructure updates included:
ci-operator/step-registry/jira-agent/README.md) with a quick-start wrapper example and required/optional env var guidance.OWNERS,*.metadata.json, and step ref YAMLs) for the setup/process/report sub-steps.Net result:
Teams can now implement their own Jira-Agent automation by creating a small wrapper workflow that points at the shared registry steps and supplies their team-specific repos, JQL, status/assignee rules, and Claude/tool setup configuration—without reimplementing the underlying multi-phase processing and reporting logic.