If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/vmware-archive/kubeless shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 4y ago

• 45+ active contributors
• Distributed ownership (top contributor 16% of recent commits)
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live vmware-archive/kubeless repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/vmware-archive/kubeless.

What it runs against: a local clone of vmware-archive/kubeless — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in vmware-archive/kubeless | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1634 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of vmware-archive/kubeless. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/vmware-archive/kubeless.git
#   cd kubeless
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of vmware-archive/kubeless and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "vmware-archive/kubeless(\\.git)?\\b" \\
  && ok "origin remote is vmware-archive/kubeless" \\
  || miss "origin remote is not vmware-archive/kubeless (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "cmd/kubeless/kubeless.go" \\
  && ok "cmd/kubeless/kubeless.go" \\
  || miss "missing critical file: cmd/kubeless/kubeless.go"
test -f "cmd/function-controller/function-controller.go" \\
  && ok "cmd/function-controller/function-controller.go" \\
  || miss "missing critical file: cmd/function-controller/function-controller.go"
test -f "cmd/kubeless/function/function.go" \\
  && ok "cmd/kubeless/function/function.go" \\
  || miss "missing critical file: cmd/kubeless/function/function.go"
test -f "cmd/kubeless/trigger/trigger.go" \\
  && ok "cmd/kubeless/trigger/trigger.go" \\
  || miss "missing critical file: cmd/kubeless/trigger/trigger.go"
test -f "Makefile" \\
  && ok "Makefile" \\
  || miss "missing critical file: Makefile"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1634 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1604d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/vmware-archive/kubeless"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Kubeless is a Kubernetes-native serverless framework that lets you deploy functions as Custom Resource Definitions (CRDs) without managing infrastructure. The in-cluster function-controller watches CRD instances and dynamically injects function code into language-specific runtimes (Go, Python, Node.js, Ruby, PHP, .NET, Ballerina), exposing them via HTTP or PubSub triggers with built-in auto-scaling and monitoring. Monorepo: cmd/kubeless/ contains the CLI (function, autoscale, topic, trigger subcommands); cmd/function-controller/ holds the in-cluster controller. pkg/ layer (inferred) likely contains shared CRD definitions and runtime handlers. Test files co-located (e.g., cmd/kubeless/autoscale/autoscale_test.go). Jsonnet configs in repo suggest templated K8s manifests.

Platform engineers and DevOps teams who want to offer serverless functions on Kubernetes clusters without external services; developers deploying event-driven workloads (cron jobs, HTTP endpoints, message-driven functions) who prefer Kubernetes-native resources over external FaaS providers.

Archived/not actively maintained as of the README notice — VMware stopped driving the project. The codebase is stable (Go 1.14, tested against K8s 1.9–1.15) with CircleCI CI/CD in place, but no new commits are expected. Production-ready at time of last update, but no ongoing security or dependency updates.

Critical risk: project is unmaintained by VMware; no active responses to issues/PRs expected. Dependency drift is inevitable (logrus v1.6.0 is old). K8s API compatibility will break as Kubernetes evolves beyond v1.15. Community forks may exist but are unofficial. Use only if you can self-maintain or have an internal fork.

Project is in maintenance-only mode — no active development. Last notable work likely involved Kubernetes 1.12–1.15 compatibility. No ongoing feature branches or PRs visible in file structure.

git clone https://github.com/vmware-archive/kubeless.git
cd kubeless
make build
# Deploy to K8s: kubectl apply -f (manifest paths vary by K8s version)

Refer to docs/dev-guide.md for full build instructions.

Daily commands: Build: make build (inferred from Makefile in root). Deploy controller: kubectl apply manifests. Test locally: go test ./... or run minikube with kubeless installed. CLI usage: kubeless function deploy, kubeless trigger http create, etc.

• cmd/kubeless/kubeless.go — Main CLI entry point; all kubeless commands are registered and dispatched here, essential for understanding command flow.
• cmd/function-controller/function-controller.go — Core controller that watches Kubernetes Function CRDs and manages their lifecycle, the heart of the serverless orchestration.
• cmd/kubeless/function/function.go — Root function command handler; coordinates deploy, delete, update, list, and describe operations across all function workflows.
• cmd/kubeless/trigger/trigger.go — Base trigger abstraction and dispatcher; all event trigger types (HTTP, Kafka, Kinesis, NATS, CronJob) inherit from this contract.
• Makefile — Build configuration and deployment targets; required to understand how the project is compiled, tested, and released.
• go.mod — Go module dependencies; minimal but critical for understanding build requirements and dependency versions.

Add a new event trigger type

1. Create trigger handler directory under cmd/kubeless/trigger/{trigger_type}/ (cmd/kubeless/trigger/{trigger_type}/{trigger_type}_trigger.go)
2. Implement create, delete, list, update commands following the pattern used in kafka_trigger.go or http_trigger.go (cmd/kubeless/trigger/{trigger_type}/create.go)
3. Define CRD structure and reconciliation logic for the trigger (often handled by function-controller) (cmd/function-controller/function-controller.go)
4. Register the trigger command in the root trigger dispatcher (cmd/kubeless/trigger/trigger.go)
5. Create a Dockerfile for any event source adapter if needed (docker/event-sources/{trigger_type}/Dockerfile)

Add a new CLI command or subcommand

1. Create a new Go file in cmd/kubeless/{command}/ following existing patterns (e.g., describe.go, logs.go) (cmd/kubeless/{command}/{subcommand}.go)
2. Use Cobra to define command flags, description, and run handler (cmd/kubeless/{command}/{subcommand}.go)
3. Register the command in its parent handler or root kubeless.go (cmd/kubeless/kubeless.go)
4. Add corresponding test file following naming convention (cmd/kubeless/{command}/{subcommand}_test.go)

Deploy a new function runtime language

1. Create a runtime-specific Dockerfile with language interpreter and kubeless function wrapper (docker/runtime/{language}/Dockerfile)
2. Update function controller to recognize and use the new runtime in pod spec generation (cmd/function-controller/function-controller.go)
3. Document the new runtime in building-functions.md with example code snippets (docs/building-functions.md)
4. Test deployment via kubeless function deploy command with appropriate --runtime flag (cmd/kubeless/function/deploy.go)

Add autoscaling policy support

1. Extend autoscale command structure to accept new metric types or policies (cmd/kubeless/autoscale/autoscale.go)
2. Implement create handler that generates appropriate Kubernetes HPA resource (cmd/kubeless/autoscale/autoscaleCreate.go)
3. Update function controller to watch and apply HPA annotations or resources (cmd/function-controller/function-controller.go)
4. Add tests to verify autoscale command acceptance and HPA resource generation (cmd/kubeless/autoscale/autoscale_test.go)

• Kubernetes CRDs (Function, Trigger, Topic) — Native Kubernetes resource model enables declarative function management, GitOps workflows, and native cluster integration without custom APIs.
• Go + Cobra CLI — Go provides fast compilation, minimal dependencies, and strong Kubernetes integration via client-go; Cobra offers composable command structure.
• Docker containers — Standardizes function runtime environments, enables polyglot language support, and integrates seamlessly with Kubernetes pod scheduling.
• Multiple event sources (HTTP, Kafka, Kinesis, NATS, CronJob) — Serverless workloads require flexibility across different event models; each trigger type is pluggable without modifying core controller.
• Kubernetes Horizontal Pod Autoscaler (HPA) — Leverages native Kubernetes autoscaling mechanisms; avoids reinventing scaling logic and maintains cluster-wide consistency.

• CRD-based architecture rather than cluster-external control plane

  • Why: Kubernetes-native approach simplifies deployment and RBAC integration.
  • Consequence: Tightly coupled to Kubernetes cluster; less portable for hybrid or multi-cluster scenarios.

• Single controller model (function-controller) rather than per-trigger-type controllers

  • Why: Simpler operational story; fewer components to deploy and manage.
  • Consequence: Controller becomes a bottleneck as trigger types scale; monitoring and debugging span all trigger concerns.

• Docker image build on-demand during function deployment

  • Why: Automatic image generation simplifies user workflow; no need for pre-built base images per language.
  • Consequence: Deployment latency increases (seconds to minutes); requires in-cluster Docker daemon or registry; potential build failures leak to deployment.

• CLI-driven workflow (no UI/dashboard) with Kubernetes-native tooling (kubectl, Helm)

  • Why: Reduces scope and dependency footprint; integrates with existing Kubernetes ecosystem familiarity.
  • Consequence: Higher barrier for non-Kubernetes users; debugging functions requires kubectl logs, not a centralized dashboard.

• Multi-cloud federation or cluster-spanning function deployment
• Function dependency management or package registries (relies on function code itself)
• Real-time function tracing or APM instrumentation (basic logs/metrics only)
• Stateful functions or data persistence beyond Kubernetes volumes
• Native support for languages outside container image (

Kubernetes version lock: code tested only up to v1.15; CRD API versions or controller runtime APIs may have breaking changes in newer clusters. No obvious env vars documented in file list — check docs/dev-guide.md for KUBECONFIG and image registry settings. Function runtimes are separate container images (not in this repo) — building a custom runtime requires separate Dockerfile. Jsonnet configs may require jsonnet tooling to regenerate K8s manifests.

• Custom Resource Definition (CRD) — Kubeless defines a 'Function' CRD to make functions first-class Kubernetes resources; understanding CRDs is essential to modifying how functions are declared and stored
• Kubernetes Operator Pattern — The function-controller is a Kubernetes operator that watches Function CRDs and orchestrates runtime pods; the pattern is central to Kubeless architecture
• Event-driven Function Invocation — Kubeless supports HTTP, cron, and PubSub triggers; understanding trigger patterns is necessary to add new event sources or debug trigger lifecycle
• Function Code Injection — The controller dynamically injects user function code into pre-built language runtimes at pod creation; this pattern enables polyglot function support without per-function container images
• Horizontal Pod Autoscaling (HPA) — Kubeless integrates Kubernetes HPA via the autoscale subcommand to scale functions based on metrics; essential for understanding the autoscale/autoscale*.go files
• Jsonnet Templating — Kubeless uses Jsonnet to generate Kubernetes manifests; understanding Jsonnet is required to modify deployment configs and manifest generation
• Kubernetes Client-Go — The Go codebase uses client-go library to interact with Kubernetes API; familiarity with client-go patterns (listers, informers, watches) is needed for controller modifications

• knative/serving — Modern alternative for Kubernetes-native serverless; also uses CRDs and runs functions in-cluster with auto-scaling
• openfaas/faas — Alternative Kubernetes serverless framework emphasizing simplicity and Docker container functions; overlaps with Kubeless on K8s-native deployments
• kubeless/kubeless-ui — Official companion UI project for managing Kubeless functions graphically instead of CLI
• serverless/serverless-kubeless — Official Serverless Framework plugin enabling Kubeless deployment via serverless.yml config files
• kubernetes/kubernetes — Kubeless depends on Kubernetes API and CRD mechanism; understanding K8s object patterns is essential

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for trigger implementations (kafka, kinesis, nats, cronjob)

The repo has trigger implementations in cmd/kubeless/trigger/* but only shows one test file (autoscaleList_test.go). Each trigger type (kafka, kinesis, nats, cronjob, http) lacks unit tests. This is critical for a serverless framework where triggers are core functionality. New contributors could add tests to verify trigger creation, deletion, listing, and update operations work correctly.

• [ ] Create cmd/kubeless/trigger/kafka/kafka_trigger_test.go with tests for Create, Delete, List, Update operations
• [ ] Create cmd/kubeless/trigger/kinesis/kinesis_trigger_test.go with tests covering stream creation and trigger management
• [ ] Create cmd/kubeless/trigger/nats/nats_trigger_test.go with NATS-specific trigger tests
• [ ] Create cmd/kubeless/trigger/cronjob/cronjob_trigger_test.go with cron schedule validation tests
• [ ] Create cmd/kubeless/trigger/http/http_trigger_test.go with HTTP endpoint and routing tests
• [ ] Ensure each test file mocks Kubernetes client interactions appropriately

Add integration tests for function deployment workflow in CircleCI

The repo has .circleci/config.yml but no visible integration test stages that verify end-to-end function deployment, invocation, and deletion. Given that kubeless is a Kubernetes framework, CircleCI should test actual function lifecycle (deploy via cmd/kubeless/function/deploy.go, call via call.go, delete via delete.go) against a test cluster.

• [ ] Update .circleci/config.yml to add a job that spins up a lightweight Kubernetes cluster (kind or minikube)
• [ ] Add workflow steps to deploy kubeless components and the function-controller
• [ ] Add test steps to deploy a sample function, invoke it, and verify output using cmd/kubeless CLI
• [ ] Add cleanup steps to verify function deletion and resource cleanup
• [ ] Document the integration test setup in CONTRIBUTING.md

Add missing unit tests for function CLI commands (deploy, describe, update, logs, top)

cmd/kubeless/function/ has several command files (deploy.go, describe.go, update.go, logs.go, top.go) but only function_test.go and list_test.go exist. These commands need tests to validate argument parsing, error handling, and Kubernetes API interactions. This is especially important for deploy.go which is a critical entry point for users.

• [ ] Create cmd/kubeless/function/deploy_test.go to test deployment validation, file parsing, and error cases
• [ ] Create cmd/kubeless/function/describe_test.go to test function metadata retrieval and formatting
• [ ] Create cmd/kubeless/function/update_test.go to test function update operations and rollback scenarios
• [ ] Create cmd/kubeless/function/logs_test.go to test log streaming and filtering
• [ ] Create cmd/kubeless/function/call_test.go to test function invocation and response handling
• [ ] Mock Kubernetes clientset and verify correct API calls in each test

• Add missing unit tests: cmd/kubeless/function/top_test.go exists but cmd/kubeless/trigger/http/ and cmd/kubeless/trigger/cronjob/ lack *_test.go files — write tests mirroring autoscale_test.go pattern to improve coverage.
• Document runtime support matrix: README mentions Go, Python, Node.js, Ruby, PHP, .NET, Ballerina but docs/runtimes.md is referenced but not shown — create a table with tested versions, required base images, and example function signatures for each.
• Add shell completion tests: cmd/kubeless/completion/completion.go exists but has no *_test.go — add tests verifying bash/zsh completions for function, trigger, and topic subcommands.

The Kubeless codebase has several concerning security issues, primarily stemming from its unmaintained status and outdated dependencies. Critical concerns include: (1) outdated Go version (1.14) with no security patches, (2) encrypted credentials in the repository (albeit encrypted), (3) an explicitly unmaintained project status, and (4) minimal visible dependency version management. The project would benefit from significant modernization, including upgrading Go and all dependencies, implementing proper secret management, and establishing a security review process if continued use is necessary. Given the 'Not Maintained' status, migration to an actively supported alternative

• High · Encrypted Credentials in Repository — .github/gcloud.json.enc. File '.github/gcloud.json.enc' appears to be an encrypted credentials file stored in the repository. While encrypted, storing any credential-related files in version control, even encrypted, is a security risk as it increases the attack surface and makes credential rotation difficult. Fix: Remove encrypted credential files from the repository. Use GitHub Secrets or similar secure secret management systems for storing credentials. Implement pre-commit hooks to prevent credential files from being committed.
• High · Outdated Go Version — go.mod. The project specifies 'go 1.14' in go.mod, which is significantly outdated (released in 2020, EOL since Jan 2021). This version lacks critical security patches and bug fixes for potential vulnerabilities in the Go runtime. Fix: Upgrade to a supported Go version (1.21 or later). Regularly update to the latest stable Go release to receive security patches and performance improvements.
• Medium · Minimal Dependency Security Information — go.mod. The provided go.mod shows only 'github.com/sirupsen/logrus v1.6.0' as an explicit dependency. Without visibility into transitive dependencies and their versions, it's difficult to assess the full attack surface. Additionally, logrus v1.6.0 is outdated (released in 2020). Fix: Run 'go mod tidy' and review all transitive dependencies. Implement dependency scanning tools like 'go list -json -m all' and use automated tools like Dependabot or Snyk to track and update vulnerable dependencies. Update logrus to the latest version.
• Medium · Project Marked as Not Maintained — README.md. The README explicitly states 'Kubeless is no longer actively maintained by VMware' with a 'Not Maintained' badge. This means security patches and vulnerability fixes are unlikely to be provided, creating a significant long-term security risk. Fix: Consider migrating to an actively maintained serverless framework for Kubernetes (e.g., Knative, OpenFaaS). If continuing to use Kubeless, establish an internal security review process and maintain a fork with security patches.
• Medium · Encrypted Configuration in Repository — .circleci/config.yml (referenced file). CircleCI configuration references 'gcloud.json.enc' which suggests encrypted GCP credentials are being used in CI/CD pipeline. While encryption is better than plaintext, this practice can lead to credential exposure if the encryption key is compromised or if credentials are accidentally logged. Fix: Use CI/CD platform's native secret management (CircleCI Context Secrets). Never store credential files, even encrypted, in the repository. Implement secret rotation policies and audit secret access.
• Low · Missing Security Policy Documentation — Repository root. There is no visible SECURITY.md or security policy file in the repository root. Given the project's unmaintained status, users lack clear guidance on how to report security vulnerabilities. Fix: Create a SECURITY.md file documenting the security reporting process, even if just redirecting to the fork maintainer. Alternatively, add security contact information in the README.
• Low · Docker Images Without Specified Base Image Versions — docker/*/Dockerfile (all Dockerfiles). Dockerfiles in the project structure (e.g., docker/function-controller/Dockerfile) are referenced but full content is not provided. If base images are pinned without version tags or use 'latest', this creates reproducibility and security issues. Fix: Use specific version tags for all base images (e.g., 'golang:1.21-alpine' instead of 'golang:latest'). Regularly scan base images for vulnerabilities using container scanning tools.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.