Vp Submission

Validated Pattern Submission Skill

When to Use

Purpose: Use this skill after vp-deploy-validator reports HEALTHY to audit whether the pattern meets Validated Patterns tier requirements and guide the developer through the PR submission process to validatedpatterns/docs.

• vp-deploy-validator just passed and you want to know what it takes to get the pattern listed on validatedpatterns.io
• You want to understand which VP tier (Community, Tested, Maintained) the pattern currently qualifies for
• You are preparing a PR to validatedpatterns/docs to list the pattern
• You want a gap analysis between current state and the next tier

Prerequisite: The pattern must deploy fully unattended (no interactive prompts in pattern.sh make install). This is checked by vp-deploy-validator Phase 1 — if a SUBMISSION_BLOCKING finding is present, resolve it before using this skill.

Do NOT use this skill to fix pattern structure issues — use the vp-refactor skill instead. Do NOT use this skill to validate a live deployment — use the vp-deploy-validator skill instead.

Instructions

This skill defines a three-phase process. Work through the phases in order.

• Read references/research-questions.md when encountering a (RESEARCH NEEDED) marker

Gotchas

• The pattern MUST deploy fully without user interaction to qualify for any tier — interactive prompts during install are an automatic rejection
• Community/Sandbox tier is the entry point — do not attempt Tested tier without passing Sandbox requirements first
• The submission PR goes to validatedpatterns/docs, not to the pattern's own repo
• CI tests in the submission repo run the full deploy cycle — ensure your pattern works on a clean cluster, not just your dev cluster
• Tier criteria are versioned — always check the current upstream requirements, as they may have changed since the skill was written

Required Input

Before starting, collect:

Phase 1 — Tier Readiness Audit

Audit the pattern repository against all three tier criteria. Report pass/fail for each check, even if the target tier is lower than Maintained — this gives the developer a full gap analysis.

Tier 1 — Community/Sandbox

The entry point for listing a pattern on validatedpatterns.io. All checks must pass.

(RESEARCH NEEDED — VP-SUB-1)

Tier 2 — Tested

Requires a working CI/CD pipeline that proves the pattern deploys automatically.

(RESEARCH NEEDED — VP-SUB-2)

Tier 3 — Maintained

Requires ongoing commitment from an active maintainer.

(RESEARCH NEEDED — VP-SUB-3)

Tier Audit Report

VP Tier Readiness Audit — <pattern-name>
══════════════════════════════════════════════════════
 Tier 1 — Community/Sandbox
  Non-interactive deploy           PASS / FAIL
  pattern-metadata.yaml present    PASS / FAIL
  values-secret.yaml excluded      PASS / FAIL
  Repo public on GitHub            PASS / FAIL
  README use case                  PASS / FAIL
  ─────────────────────────────────
  Tier 1 overall:                  READY / NOT READY

 Tier 2 — Tested
  CI/CD pipeline exists            PASS / FAIL / N/A
  Pipeline runs on push            PASS / FAIL / N/A
  OCP version declared             PASS / FAIL / N/A
  Convergence check in CI          PASS / FAIL / N/A
  Lab/demo documentation           PASS / FAIL / N/A
  ─────────────────────────────────
  Tier 2 overall:                  READY / NOT READY / GAPS

 Tier 3 — Maintained
  OWNERS file present              PASS / FAIL / N/A
  Dependency updates recent        PASS / FAIL / N/A
  RH/community involvement         PASS / FAIL / N/A
  Issue/PR SLA met                 PASS / FAIL / N/A
  ─────────────────────────────────
  Tier 3 overall:                  READY / NOT READY / GAPS
══════════════════════════════════════════════════════
 Highest tier achieved:  Community / Tested / Maintained / NONE
 Recommended action:     submit at <tier> / resolve gaps first

If any Tier 1 check fails, stop. The pattern cannot be submitted at any tier until all Tier 1 checks pass.

Phase 2 — Gap Remediation Plan

For any tier the developer wants to target, produce an ordered remediation plan for checks that failed.

VP Submission Gap Plan — <pattern-name> → target: <tier>
──────────────────────────────────────────────────────
Priority  #  Gap                               Action
BLOCKING  1  pattern.sh requires interaction   Fix interactive prompts → vp-deploy-validator
BLOCKING  2  pattern-metadata.yaml missing     Create file with required fields (see RQ VP-SUB-1)
HIGH      3  No CI/CD pipeline                 Add GitHub Actions workflow calling pattern.sh make install
MEDIUM    4  No OCP version declared           Add tested-ocp-versions to pattern-metadata.yaml
──────────────────────────────────────────────────────

Present only the gaps for the chosen target tier. Ask:

"Would you like to address item 1 now? (y/n)"

If yes for structural issues, activate vp-refactor. If yes for CI/CD setup, provide the GitHub Actions workflow template below.

GitHub Actions CI Template (Tier 2 baseline)

# .github/workflows/validate-pattern.yml
name: Validate Pattern
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up oc
        uses: redhat-actions/openshift-tools-installer@v1
        with:
          oc: latest

      - name: Login to OCP
        run: |
          oc login ${{ secrets.OCP_API_URL }} \
            --token=${{ secrets.OCP_TOKEN }} \
            --insecure-skip-tls-verify

      - name: Install pattern
        run: ./pattern.sh make install

      - name: Wait for ArgoCD convergence
        run: |
          for i in $(seq 1 30); do
            NOT_HEALTHY=$(oc get applications -n openshift-gitops \
              -o jsonpath='{range .items[*]}{.status.health.status}{"\n"}{end}' \
              | grep -v Healthy | wc -l)
            [ "$NOT_HEALTHY" -eq 0 ] && echo "All healthy" && exit 0
            echo "Waiting... ($i/30)"
            sleep 30
          done
          echo "Convergence timeout" && exit 1

(RESEARCH NEEDED — VP-SUB-2)

Phase 3 — Submission PR Guidance

Once the pattern passes all checks for the chosen tier, guide the developer through submitting a PR to validatedpatterns/docs.

Step 1 — Fork the docs repo

gh repo fork validatedpatterns/docs --clone
cd docs

Step 2 — Understand the content structure

(RESEARCH NEEDED — VP-SUB-4)

Current partial guidance (verify against the live repo before filing a PR):

The docs repo uses Hugo with AsciiDoc content. Pattern pages live under content/. Based on the repo structure at github.com/validatedpatterns/docs, a pattern entry includes:

• A directory under content/patterns/<pattern-name>/
• An _index.adoc file with Hugo frontmatter
• A getting-started.adoc file with installation instructions

Step 3 — Create the pattern page

mkdir -p content/patterns/<pattern-name>

Minimum _index.adoc frontmatter:

---
title: <Pattern Display Name>
date: <YYYY-MM-DD>
tier: community|tested|maintained
summary: <One sentence describing what the pattern does>
rh_products:
  - <Red Hat Product Name>
industries:
  - <Industry>
---

(RESEARCH NEEDED — VP-SUB-4)

Step 4 — Submit the PR

git checkout -b add-<pattern-name>-pattern
git add content/patterns/<pattern-name>/
git commit -m "feat: add <pattern-name> at <tier> tier"
git push origin add-<pattern-name>-pattern
gh pr create \
  --repo validatedpatterns/docs \
  --title "feat: add <pattern-name> pattern (<tier> tier)" \
  --body "$(cat <<'EOF'
## Summary

- Adds pattern page for <pattern-name>
- Tier: <community|tested|maintained>
- Pattern repo: <GitHub URL>

## Checklist

- [ ] Pattern deploys without user interaction
- [ ] pattern-metadata.yaml present and valid
- [ ] values-secret.yaml excluded from git
- [ ] README explains use case

EOF
)"

Step 5 — Reviewer expectations

(RESEARCH NEEDED — VP-SUB-5)

Current partial guidance:

• The VP team reviews for tier compliance — the checklist in the PR body should match the audit from Phase 1
• A link to a recent successful CI run or a recorded demo strengthens the submission
• Expect review comments within 1–2 weeks from the validatedpatterns maintainers

Submission Report

VP Submission — <pattern-name>
══════════════════════════════════════════════════════
 Target tier:    <community|tested|maintained>
 PR filed:       <PR URL>
 Pattern repo:   <GitHub URL>
 Submitted by:   <GitHub handle>

 Tier 1 audit:   PASS
 Tier 2 audit:   PASS / N/A
 Tier 3 audit:   PASS / N/A

 Status:  PR SUBMITTED — awaiting VP team review
══════════════════════════════════════════════════════

Escalation

• Non-interactive install failure → Use vp-deploy-test to re-validate after fixing interactive prompts; confirm vp-deploy-validator shows no SUBMISSION_BLOCKING finding
• Structural pattern issues (values, charts, secrets) → Use vp-refactor to audit and fix before re-running Phase 1
• pattern-metadata.yaml missing or malformed → Use vp-refactor for structural audit, then resolve VP-SUB-1 via skill-researcher
• PR rejected by VP team → Review reviewer comments, address findings, and re-run Phase 1 audit before re-submitting