// Use when user asks about Konflux resources, Custom Resources, Applications, Components, Snapshots, IntegrationTestScenarios, ReleasePlans, ReleasePlanAdmissions, or namespace placement. Provides quick reference for what Konflux resources are, who creates them, and where they belong (tenant vs managed namespace).
| name | understanding-konflux-resources |
| description | Use when user asks about Konflux resources, Custom Resources, Applications, Components, Snapshots, IntegrationTestScenarios, ReleasePlans, ReleasePlanAdmissions, or namespace placement. Provides quick reference for what Konflux resources are, who creates them, and where they belong (tenant vs managed namespace). |
Konflux uses Kubernetes Custom Resources (CRs) to manage CI/CD workflows. Understanding which resource to use, who creates it, and where it belongs prevents common configuration errors.
Core principle: Some resources YOU create, others Konflux creates automatically. Knowing the difference prevents manual work that's already automated.
NAMING CONVENTION - CRITICAL:
Always write resource names WITHOUT spaces: ReleasePlan, ReleasePlanAdmission, IntegrationTestScenario
NEVER use spaces: "Release Plan", "Release Plan Admission", "Integration Test Scenario"
⚠️ COMMON HALLUCINATION - MUST CORRECT: ReleasePlanAdmission (RPA) is NOT automatically created by Konflux. ReleasePlanAdmission (RPA) is NOT auto-generated by the release service. ReleasePlanAdmission (RPA) IS manually created by a Platform Engineer in the managed namespace.
WHO CREATES WHAT - Critical Facts:
NAMESPACE PLACEMENT - Critical for RP/RPA:
Common abbreviations: RP (ReleasePlan), RPA (ReleasePlanAdmission), ITS (IntegrationTestScenario), App (Application), Comp (Component)
CRITICAL: Konflux has specific resource names. Do NOT invent resource names like "ApplicationSource", "DevBuildTemplate", "BuildConfig", etc. Use ONLY the resources listed in the table below.
Use this skill when:
| Resource | Abbrev | Purpose | Who Creates | Namespace | Key Point |
|---|---|---|---|---|---|
| Application | App | Groups related Components that deploy together (NO git URL, NO builds) | User | Tenant | Just a label for grouping |
| Component | Comp | Defines how to build artifact from git repo/branch (HAS git URL) | User | Tenant | This is what builds your code |
| Snapshot | - | Immutable set of component artifact references | Konflux (Integration Service) | Tenant | AUTO-CREATED after builds |
| IntegrationTestScenario | ITS | Defines test to run against snapshot | User | Tenant | Tests run after build |
| ReleasePlan | RP | Maps Application to release action | User | Tenant | Created by app owner |
| ReleasePlanAdmission | RPA | Defines release pipeline + credentials | Platform Engineer | Managed | Contains secrets |
| Release | - | Request to release specific snapshot | User | Tenant | References snapshot + plan |
✅ CORRECT: Snapshots are AUTO-CREATED by Integration Service after successful builds. You never manually create them.
✅ CORRECT: ReleasePlan goes in YOUR tenant namespace. ReleasePlanAdmission (with credentials) goes in managed namespace.
✅ CORRECT: Platform Engineer manually creates RPA in managed namespace. RPA is NOT auto-created, NOT auto-generated. It's a manual step by platform team.
✅ CORRECT: If they deploy together, create 1 Application with 5 Components (one Component per repo).
✅ CORRECT: Use Component to build from git repo. Application just groups Components together.
✅ CORRECT: Application = the system, Component = each microservice that builds separately.
✅ CORRECT: Component contains git URL and builds code. Application is just a logical grouping label.
Q: "I need to build my app from a git repository"
A: Create a COMPONENT resource
- Exact resource name: "Component"
- API: appstudio.redhat.com/v1alpha1
- One Component per repo/branch you want to build
Q: "I have multiple repos that deploy together"
A: Create 1 APPLICATION + multiple COMPONENTs
- Application resource groups them
- One Component per repo
Q: "I want to run tests after builds"
A: Create INTEGRATIONTESTSCENARIO resource
- References a Tekton pipeline with your tests
Q: "I want to release a built snapshot"
A: Create RELEASE resource
- References existing Snapshot + ReleasePlan
Q: "I'm setting up a release pipeline"
A: Two resources needed:
- User creates: RELEASEPLAN in tenant namespace
- Platform Engineer creates: RELEASEPLANADMISSION in managed namespace
Q: "I need a snapshot of my builds"
A: DON'T CREATE MANUALLY
- Konflux auto-creates Snapshot resources after builds
- Just reference existing snapshots
Tenant Namespace (your workspace):
Managed Namespace (restricted, controlled by platform team):
Why this separation? Keeps release credentials isolated from dev teams while allowing devs to request releases.
CRITICAL for RP/RPA: ReleasePlan and ReleasePlanAdmission are in DIFFERENT namespaces. RP (tenant) references application. RPA (managed) references RP and contains credentials. They work together across namespace boundaries.
Initial Setup (you do once):
Every Code Push (Konflux automates):
When Ready to Release:
You create: Application, Component, IntegrationTestScenario, Release Konflux creates: Snapshot, PipelineRuns
Think hierarchy:
Application (e.g., "E-commerce Platform")
├── Component: frontend-ui (built from repo A, main branch)
├── Component: backend-api (built from repo B, main branch)
├── Component: auth-service (built from repo C, main branch)
└── Component: payment-processor (built from repo D, v2 branch)
Application = logical grouping, deploy together Component = buildable unit, one per git source
Scenario: One repo with frontend code
Resources:
- 1 Application: "my-web-app"
- 1 Component: "my-web-app-frontend" (points to repo main branch)
- Snapshots: Auto-created on every build
Scenario: frontend, backend, auth, data, queue repos that deploy together
Resources:
- 1 Application: "payment-system"
- 5 Components: (one per repo)
- payment-frontend
- payment-backend
- payment-auth
- payment-data
- payment-queue
- Snapshots: Auto-created after each component builds
Scenario: Run security scan after build
Resources:
- 1 IntegrationTestScenario: "security-scan"
- References Tekton pipeline that runs scanning tools
- Runs automatically on every new Snapshot
Scenario: Release to production
In Tenant Namespace:
- ReleasePlan: "prod-release-plan"
- Points to Application
- References target workspace
In Managed Namespace (Platform Engineer creates):
- ReleasePlanAdmission: "prod-admission"
- Contains production credentials
- Defines release pipeline
To Release:
- Create Release CR in tenant namespace
- References specific Snapshot (auto-created earlier)
- References ReleasePlan
| Mistake | Why It Fails | Fix |
|---|---|---|
| Creating Snapshot manually | They're auto-created | Just reference existing snapshots |
| ReleasePlan in managed namespace | User can't create there | ReleasePlan in tenant, ReleasePlanAdmission in managed |
| One Component for multiple repos | Can't build from multiple sources | One Component per repo |
| Creating Application per service | Loses deployment grouping | One Application, multiple Components |
| IntegrationTestScenario in managed namespace | Tests run in tenant namespace | Put in tenant namespace |
"Snapshot not found"
kubectl get snapshots -n <tenant-namespace>"ReleasePlan not found"
"No builds triggering"
"Integration tests not running"
Konflux resources, Custom Resource Definition, CRD, Application CR, Component CR, Snapshot lifecycle, IntegrationTestScenario, ReleasePlan, ReleasePlanAdmission, Release CR, tenant namespace, managed namespace, build pipeline, PipelineRun, Integration Service, Build Service, Release Service, Tekton pipeline, OCI artifact, container image, git repository, webhook, automatic build, snapshot creation, integration testing, release workflow, RP, RPA, ITS, App, Comp, shortname, abbreviation, acronym, ReleasePlan abbreviation, IntegrationTestScenario abbreviation, ReleasePlanAdmission abbreviation
Use this skill to query Konflux objects from the Kubernetes cluster. Konflux objects are application, component, pipelinerun, taskrun, snapshot and release. The skill can be used to query logs from failed or removed pipelines and pods.
Use when tracing Konflux builds from image references, finding build logs from artifacts, or verifying source commits for container images - extracts provenance attestations to navigate from images back to builds and source code
Use when GitHub PR or branch has failing checks and you need to find Konflux pipeline information (cluster, namespace, PipelineRun name). Teaches gh CLI commands to identify Konflux checks (filter out Prow/SonarCloud), extract PipelineRun URLs from builds and integration tests, and parse URLs for kubectl debugging.
Use when Konflux pipelines fail, are stuck, timeout, or show errors like ImagePullBackOff. Covers PipelineRun failures, TaskRun issues (Pending, Failed, stuck Running), build errors, and systematic debugging of Tekton pipeline problems using kubectl and logs.
Use when user asks to "test skill invocation framework" or mentions "canary skill test". This is a self-test skill to verify the test framework correctly loads and invokes skills.