Skip to content

Latest commit

 

History

History
69 lines (49 loc) · 4.77 KB

File metadata and controls

69 lines (49 loc) · 4.77 KB

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

What this repository is

A curated collection of example Fission functions and applications, organized by language and use case. This is not an application codebase with a build/test pipeline — it is a catalog of standalone samples meant to be deployed onto a Fission/Kubernetes cluster. Each example is self-contained and demonstrates one concept (a language runtime, a trigger type, a deployment strategy, an integration, etc.).

Most "commands" in this repo are fission CLI invocations that target a live cluster, not local build/test commands. You generally cannot run these examples without a Kubernetes cluster with Fission installed.

Layout

Top-level directories are language buckets (python/, python-fastapi/, go/, nodejs/, java/, dotnet/, dotnet8/, ruby/, perl/, php7/, rust/) plus miscellaneous/ for cross-cutting use cases (message-queue triggers, specs, containers, observability, websockets, long-running functions, etc.).

The two ways a function gets deployed

Every example follows one of these patterns. Recognize which one before editing.

  1. Single-file / inline — deploy the source directly with the CLI:

    fission environment create --name python --image ghcr.io/fission/python-env
    fission function create --name hello-py --env python --code hello.py
    fission function test --name hello-py
    
  2. Spec-based — a specs/ directory deployed atomically with fission spec apply --wait. Spec dirs always contain fission-deployment-config.yaml (holds a generated uid — never edit the uid, it breaks spec apply), an env-*.yaml (kind: Environment), and function-*.yaml (kind: Function). Builder-based languages add a package-*.yaml (kind: Package + ArchiveUploadSpec). These YAMLs are generated by fission spec init / fission spec apply; preserve their structure and apiVersion: fission.io/v1.

Function entrypoint conventions (differ per language)

When adding or fixing a function, match the runtime's expected signature:

  • Python — module-level def main(): (Flask request/current_app available via import).
  • Node.js — module.exports = async function(context) { return { status, body } }.
  • Go — func Handler(w http.ResponseWriter, r *http.Request), package main. Deployed with --entrypoint Handler.
  • Ruby — top-level def handler.
  • Java — class implementing the Fission Function interface (e.g. io.fission.HelloWorld); function name in the spec is the FQCN.
  • .NET (legacy dotnet/) — single .cs file; the function body is the file.
  • .NET 8 (dotnet8/) — class with public object Execute(FissionContext context); entrypoint is the FQ Namespace.Class (built via --buildcmd /usr/local/bin/build).
  • PHP — plain script; $logger is injected.
  • Rust — single-file mode: pub async fn handler with any axum handler signature. Cargo-project mode: a binary crate that serves HTTP on 127.0.0.1:$FISSION_RUNTIME_PORT (any framework works).

Builder vs. runtime environments

Interpreted single-file examples use the runtime image only. Examples with dependencies (Go modules, Java/Maven, Python requirements.txt) need a builder environment and a build.sh. build.sh runs inside the builder container and uses ${SRC_PKG} (input) and ${DEPLOY_PKG} (output) env vars — e.g. install deps into ${SRC_PKG}, then cp -r ${SRC_PKG} ${DEPLOY_PKG}. Java's build.sh instead shells out to a Maven Docker image so no local JDK is needed.

Catalog metadata

Each language dir has an examples.json (flat entries: name/description/path/tag/language); the ones under miscellaneous/ (including message-queue-trigger/ and spec-example/) feed the "Misc" group. These files are the source of truth for the examples catalog rendered at fission.io/examples. When you add a new example, add a corresponding entry so it shows up.

The catalog UI lives in the fission/fission.io repo, not here. Its tools/examples.py reads these per-language files, groups them by language, adds logos/group tags, and regenerates static/data/examples.json (a different, grouped schema using link/tags). After editing an examples.json here, that script must be re-run in the fission.io repo to refresh the site.

Conventions

  • Each example directory should have its own README.md showing the exact fission ... deploy/test commands for that sample — keep this when editing.
  • Markdown: one sentence per line within paragraphs.
  • target/ (Java build output) and node_modules/ are committed in some examples but are generally build artifacts; do not regenerate or hand-edit them.