Submit and Review

Create a pull request for the E2E test fix, trigger automated review, address feedback, and verify CI passes.

When to Use

Use this skill after verifying the fix (via e2e-verify-fix) when all tests pass and code quality checks are clean.

Step 0: Resolve Pre-Commit Hooks

Before committing, ensure all related workspaces have their dependencies installed so pre-commit hooks (lint-staged, rulesync, etc.) pass:

# Root workspace
yarn install

# If e2e-tests files were changed
cd e2e-tests && yarn install && cd ..

# If .ci files were changed
cd .ci && yarn install && cd ..

If a pre-commit hook fails during commit, fix the issue and create a new commit — do not amend.

Step 1: Commit Changes

Stage and Commit

# Stage only relevant files
git add e2e-tests/
git add .ci/  # Only if deployment config was changed

# Commit with a descriptive message
git commit -m "fix(e2e): <short description of what was fixed>

<Longer description if needed explaining:>
- What test was failing
- What the root cause was
- How it was fixed"

Commit Message Convention

Follow the conventional commit format:

• fix(e2e): fix flaky topology test timeout
• fix(e2e): update RBAC page locators after UI redesign
• fix(e2e): add retry logic for catalog entity refresh
• fix(e2e): skip orchestrator test on GKE platform

If a Jira ticket exists, reference it:

• fix(e2e): fix topology locator drift [RHIDP-1234]

Step 2: Push to Fork

Push the fix branch to the fork (origin):

git push -u origin <branch-name>

Example:

git push -u origin fix/e2e-topology-locator
# or
git push -u origin fix/RHIDP-1234-e2e-topology-locator

Step 3: Create Pull Request

Create a PR against the upstream redhat-developer/rhdh repository.

Dynamic username extraction -- Always derive the GitHub username from the fork remote at runtime rather than hardcoding it. This makes the workflow portable across any contributor's environment:

GITHUB_USER=$(git remote get-url origin | sed 's|.*github.com[:/]||;s|/.*||')

Then create the PR as a draft (always use --draft):

gh pr create \
  --draft \
  --repo redhat-developer/rhdh \
  --head "${GITHUB_USER}:<branch-name>" \
  --base <release-branch> \
  --title "fix(e2e): <description> [AI /e2e-fix]" \
  --body "$(cat <<'EOF'
## Summary
- <1-2 bullet points explaining what was fixed and why>

## Test Results
- Local verification: 5/5 passes
- Code quality: Oxlint, Oxfmt, and applicable ShellCheck/unit tests pass

## Related
- Prow job: <URL if applicable>
- Jira: <ticket ID if applicable>
EOF
)"

Important: Always use --repo redhat-developer/rhdh and --head <username>:<branch> for cross-fork PRs. Never hardcode the GitHub username -- always extract it dynamically from the origin remote URL so this workflow works for any contributor.

PR Description Guidelines

Keep it concise:

• What test was failing
• What the root cause was
• How it was fixed
• Link to the original failing CI job or Jira ticket

Step 4: Trigger Qodo Agentic Review

After the PR is created, trigger an agentic review from Qodo (PR-Agent):

# Get the PR number from the create output, then comment
gh pr comment <PR-number> --repo redhat-developer/rhdh --body "/agentic_review"

The Qodo bot will:

1. Analyze the code changes
2. Post review comments with suggestions
3. Optionally approve or request changes

Step 5: Wait for and Address Qodo Review

Poll for Review Comments

Poll for Qodo review completion (typically takes 1-3 minutes):

# Poll for Qodo bot review (check every 15s, up to 20 attempts = 5 min)
for i in $(seq 1 20); do
  REVIEW_STATE=$(gh api repos/redhat-developer/rhdh/pulls/<PR-number>/reviews \
    --jq '[.[] | select(.user.login | test("github-actions|qodo|codium|pr-agent"))] | last | .state // empty')
  if [[ -n "$REVIEW_STATE" ]]; then
    echo "Qodo review received (state: $REVIEW_STATE)"
    break
  fi
  echo "Waiting for Qodo review (attempt $i/20)..."
  sleep 15
done

If a review is received, fetch the inline comments:

# Get inline review comments
gh api repos/redhat-developer/rhdh/pulls/<PR-number>/comments \
  --jq '.[] | select(.user.login | test("github-actions|qodo|codium|pr-agent")) | {path: .path, line: .line, body: .body}'

If no review is received after 5 minutes, ask the user for guidance.

Address Review Comments

For each review comment:

1. Code suggestions: If the suggestion improves the code, apply it:

# Make the change locally
# Then stage only the changed files and commit
git add <specific-files>
git commit -m "fix(e2e): address review feedback"
git push

Never use git add -A or git add . — always stage specific files to avoid committing .env, test artifacts, or other local-only files.

2. Style/convention issues: Fix them per project conventions
3. False positives: If a suggestion is incorrect, explain why in a reply:

gh api repos/redhat-developer/rhdh/pulls/<PR-number>/comments/<comment-id>/replies \
  -f body="This is intentional because <reason>"

4. Questions: Answer them with context from the codebase

Step 6: Trigger Affected CI Job

After addressing Qodo review feedback (and pushing any follow-up commits), trigger the presubmit E2E job that corresponds to the originally failing CI job. Presubmit job names differ from periodic/nightly names but cover the same platform and deployment method.

CRITICAL: Never guess or construct presubmit job names. Always discover them from the openshift-ci bot response as described below.

Step 6a: Request Available Jobs

Comment /test ? on the PR to request the list of available presubmit jobs:

gh pr comment <PR-number> --repo redhat-developer/rhdh --body "/test ?"

Step 6b: Wait for the Bot Response

The bot usually responds within seconds. Poll PR comments for the openshift-ci bot's response:

# Poll for the openshift-ci bot response (check every 5s, up to 12 attempts = 1 min)
for i in $(seq 1 12); do
  BOT_RESPONSE=$(gh api repos/redhat-developer/rhdh/issues/<PR-number>/comments \
    --jq '[.[] | select(.user.login == "openshift-ci[bot]" or .user.login == "openshift-ci-robot")] | last | .body // empty')
  if [[ -n "$BOT_RESPONSE" ]] && echo "$BOT_RESPONSE" | grep -q '/test'; then
    echo "Bot response received:"
    echo "$BOT_RESPONSE"
    break
  fi
  echo "Waiting for openshift-ci bot response (attempt $i/12)..."
  sleep 5
done

If no response is received after 1 minute, ask the user for guidance.

Step 6c: Understand the Bot Response

The bot's response has two sections:

1. Required jobs — triggered automatically when the PR is marked as ready for review (not on draft PRs). These run the basic presubmit checks:

/test e2e-ocp-helm

2. Optional jobs — must be triggered explicitly. These include nightly variants, other platforms, and operators:

/test e2e-ocp-helm-nightly
/test e2e-eks-helm-nightly
/test e2e-aks-operator-nightly
...

Note: the job names in the bot's response are shortened (e.g., e2e-ocp-helm), not the full Prow pull-ci-redhat-developer-rhdh-... format. Use these short names directly with /test.

Step 6d: Select and Trigger the Right Job

Match the original failure to the right presubmit job from the bot's list:

gh pr comment <PR-number> --repo redhat-developer/rhdh --body "/test <job-name-from-bot-response>"

Rules:

• Only use job names that appeared in the bot's response — never construct or guess names
• The required job (e2e-ocp-helm) runs automatically — you usually only need to trigger the optional job matching the original failure
• If no matching job exists in the list, inform the user and ask how to proceed

Step 7: Monitor CI Status

Watch CI Checks

After pushing changes, monitor the CI pipeline:

gh pr checks <PR-number> --repo redhat-developer/rhdh --watch

Or check manually:

gh pr checks <PR-number> --repo redhat-developer/rhdh

CI check types (Prow E2E jobs, lint checks, build checks, etc.) are documented in the project CI rules. Use gh pr checks output to identify which specific check failed.

If CI Fails

1. E2E test failure: Check the Prow job logs, determine if it's the same test or a different one
2. E2E lint failure: Run yarn lint:fix from e2e-tests/, then rerun its lint and formatting checks before committing
3. Application build failure: Check TypeScript errors with yarn tsc from the repository root; the E2E workspace has no separate tsc:check script
4. Unrelated failure: Comment on the PR noting it's an unrelated failure, optionally /retest to re-trigger

Re-trigger CI

If a CI check needs to be re-run:

# For Prow jobs, comment on the PR
gh pr comment <PR-number> --repo redhat-developer/rhdh --body "/retest"

# For specific jobs
gh pr comment <PR-number> --repo redhat-developer/rhdh --body "/retest <job-name>"

Step 8: Final Status Report

After CI passes (or all issues are addressed), produce a final report:

PR Status Report:
- PR: <URL>
- Branch: <branch> -> <release-branch>
- CI Status: PASS / PENDING / FAIL
- Qodo Review: Addressed / Pending
- Files changed: <count>
- Action items: <any remaining items>

Quick Reference: PR Workflow Commands

# Determine GitHub username from fork remote
GITHUB_USER=$(git remote get-url origin | sed 's|.*github.com[:/]||;s|/.*||')

# Create draft PR (always use --draft)
gh pr create --draft --repo redhat-developer/rhdh --head "${GITHUB_USER}:<branch>" --base <release-branch> --title "fix(e2e): <description> [AI /e2e-fix]"

# Trigger Qodo review
gh pr comment <PR#> --repo redhat-developer/rhdh --body "/agentic_review"

# List available presubmit jobs (Step 6a)
gh pr comment <PR#> --repo redhat-developer/rhdh --body "/test ?"

# Wait for openshift-ci bot response (Step 6b) -- poll until bot replies with job list

# Trigger specific presubmit job (Step 6d) -- ONLY use a job name from the bot's response
gh pr comment <PR#> --repo redhat-developer/rhdh --body "/test <job-name-from-bot-response>"

# Check CI status
gh pr checks <PR#> --repo redhat-developer/rhdh

# Re-trigger tests
gh pr comment <PR#> --repo redhat-developer/rhdh --body "/retest"

# View PR
gh pr view <PR#> --repo redhat-developer/rhdh --web