frontend-forge-fe-operations

Operate FrontendExtension package, publish, and unpublish lifecycles in Kubernetes clusters.

17.0k|2.8k|Updated Apr 21, 2018
One-click install
npx skills add https://github.com/kubesphere/kubesphere --skill frontend-forge-fe-operations
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: frontend-forge-fe-operations
Source: https://github.com/kubesphere/kubesphere/tree/main/skills/frontend-forge-fe-operations
Command: npx skills add https://github.com/kubesphere/kubesphere --skill frontend-forge-fe-operations

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Managing FrontendExtension (FE) custom resources in a KubeSphere frontend-forge environment involves many moving parts: package Jobs, artifact ConfigMaps, publish targets, and controller status fields. This Skill provides the exact kubectl and API workflows to create, rebuild, download, publish, unpublish, delete, and debug FE resources without guessing at labels, annotations, or status semantics.

Core Features & Use Cases

  • Full FE Lifecycle Operations: Create or update FE manifests, force rebuilds via the rebuild-token annotation, download package artifacts, and publish or unpublish through the FE HTTP API with digest protection.
  • Inspection and Troubleshooting: Diagnose stuck or failed package, publish, and unpublish phases by reading FE status, conditions, labels, Job logs, artifact ConfigMaps, and controller logs in a defined order.
  • Safety Guardrails: Enforces safe deletion with unpublish-first flows, prevents manual mutation of controller-owned artifact ConfigMaps, and treats raw annotation patches as a last-resort recovery path.
  • Use Case: An operator notices an FE stuck in the Packaging phase. The Skill guides them to check status.conditions, locate the package Job from status.packageJob, read its logs, verify build-service reachability, and inspect the artifact ConfigMap before escalating to controller logs.

Quick Start

Ask the assistant to inspect the FrontendExtension named inspecttask, explain why it is stuck in Packaging, and show the package Job logs and artifact ConfigMap status.

Frequently Asked Questions about frontend-forge-fe-operations

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I publish a FrontendExtension in KubeSphere?

Publish through the FE HTTP API at /kapis/frontend-forge-api.kubesphere.io/v1alpha1/frontendextensions/<name>/publish with a POST body containing a requestId and optionally expectedArtifactDigest. The API validates artifact readiness and returns 202 Accepted, then a publisher Job runs; track it via status.publish.jobRef.

How do I force a FrontendExtension package rebuild?

Set the frontend-forge.kubesphere.io/rebuild-token annotation on the FE to a unique value such as a timestamp using kubectl annotate with --overwrite. This changes artifact cache identity and triggers a new package Job; wait for status.phase=Ready before downloading or republishing.

Why is my FrontendExtension stuck in the Packaging phase?

A stuck Packaging phase usually means the package Job is failing or the build service is unreachable. Check status.conditions and status.packageJob, read the package Job logs, verify BUILD_SERVICE_BASE_URL reachability, and confirm the artifact ConfigMap metadata matches FE status.

Does kubectl delete fe unpublish a published extension?

No, direct kubectl delete removes the FE custom resource without running unpublish. Use the FE API delete endpoint with {"unpublish":true} so the controller unpublishes first; it returns 202 Accepted and creates an unpublish Job before deletion completes.

Why did changing publishPolicy not trigger a package rebuild?

This is expected behavior because the source hash excludes publishPolicy and only covers package/source identity. Verify freshness with status.observedSourceHash, status.artifact.artifactKey, and the publish-fresh label; use the rebuild-token annotation only if you genuinely need a new artifact.

Can I edit the artifact ConfigMap to fix a bad package?

No, artifact ConfigMaps are controller-owned outputs and editing binaryData package.tgz, artifact.json, or files.json can make status, annotations, and digest disagree. Use the FE API download endpoint for package bytes and trigger a rebuild instead of manual edits.