E2E Submit And Review

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: lint, tsc, prettier all 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 ?"