OCI Functions Deploy

Overview

Use this skill for local macOS/Linux OCI Functions workstations. Windows automation is out of scope for this skill and should be handled manually. OCI Cloud Shell is also out of scope for the current workflow; if the user is in Cloud Shell, do not reuse this local automation flow blindly.

This skill supports Java, Python, and Node scaffolding and deploy automation. OCI Functions supports additional runtimes, but they are not scaffolded or deployed automatically by this skill.

Resolve deployment values with this precedence everywhere in the flow:

• explicit user-provided values collected in chat or passed as script flags
• active Fn context values
• derived values from already-resolved inputs
• OCI/CLI defaults

Execution modes:

• interactive: confirmations are gathered via terminal prompts for mutating actions.
• agent-mediated: confirmations are per-command and single-use. Approval must include CONFIRM_RESPONSE=yes, a matching CONFIRM_ACTION_ID, and the nonce emitted for that exact mutation in CONFIRM_NONCE.

Read vs Mutate Policy

• read: dependency checks, context inspection, OCI session validation, Docker auth inspection, application listing, dry-run validation. Run without confirmation.
• mutate: install/start, create/update contexts, Docker login, app creation, advanced network creation, fn init, and fn deploy. Require confirmation.
• If a command is ambiguous, treat it as mutating and confirm it.

Gating Table

Step	Classification	Confirmation
dependency availability checks	read	not required
Fn context inspection	read	not required
OCI session validation and security-token retry check	read	not required
Docker registry auth inspection	read	not required
install missing fn / oci / docker	mutate	required
start Docker daemon	mutate	required
create or update Fn context	mutate	required
Docker login to Fn registry	mutate	required
create Functions app	mutate	required
advanced network creation (ensure_network.sh)	mutate	required
scaffold function with fn init	mutate	required
deploy with fn deploy	mutate	required

Confirm Interface

Mutating scripts must use the structured confirmation interface:

confirm_gate.sh --description <text> [--display <text>] [--cwd <path>] [--stdin-env <env>] [--nonce <nonce>] [--machine-readable] -- <argv...>

Rules:

• Execute argv directly, not through bash -c.
• Use --cwd instead of embedding cd ... && ....
• Use --stdin-env for commands like docker login --password-stdin.
• Agent-mediated approvals are single-use. Replaying the same action id and nonce after a successful mutation is invalid.
• Interactive prompts mint a fresh 128-bit nonce from /dev/urandom for each mutation prompt so the same command can be approved again later through a new prompt.
• Confirmation descriptions and caller-supplied display text are shell-escaped for review; execution still uses only the original argv array.
• Linux Fn installation resolves the latest non-draft, non-prerelease GitHub release before confirmation. The approved action is bound to that release's canonical asset URL and GitHub-provided SHA-256 digest. The installer revalidates the metadata, digest, and reported binary version before privileged installation and never executes a downloaded shell installer.
• The verified Linux Fn install path requires curl, python3, and either sha256sum or shasum; if one is unavailable, install that prerequisite first or install Fn manually.
• Verified latest-release installation still trusts the official fnproject/cli repository, GitHub release metadata, and the upstream release publisher.

Function Name Rules

• Treat a function name as provided only when the user explicitly names it.
• Explicit naming includes phrases like name it ..., call it ..., function name is ..., or a structured flag such as --function-name.
• Descriptive phrases such as hello world function, sample function, test function, or python function describe intent only and must not be converted into a function name automatically.
• Never slugify a descriptive phrase into a function name without asking the user.
• It is acceptable to suggest a name derived from intent, but the user must explicitly confirm it before it is used.

Function Name Contract

• function_name_state=missing: no explicit or prompted function name exists yet.
• function_name_state=explicit: the user explicitly named the function in chat or via --function-name with --function-name-source explicit.
• function_name_state=prompted: the name was gathered or confirmed via an explicit prompt.
• Only pass --function-name into build_and_deploy.sh when the state is explicit or prompted.
• If a likely name was inferred from prose, keep the state as missing and ask for the function name instead of forwarding it.

Workflow

1. Dependency availability

• Run scripts/preflight_check.sh --runtime <java|python|node> to detect whether fn, oci, and docker are installed.
• If fn or oci is missing, prompt and run scripts/install_missing.sh --tool <fn|oci>.
• If Docker is missing, prompt and run scripts/install_missing.sh --tool docker.
• If Docker exists but the daemon is stopped, prompt and run scripts/install_missing.sh --tool docker-daemon.

2. Fn context validation

• Use fn inspect context as the primary source of oracle.profile, oracle.compartment-id, api-url, and registry.
• Precedence is always: explicit user-provided values and script flags, then the active Fn context, then derived values, then OCI/CLI defaults.
• If the active Fn context is missing or incomplete, collect only missing values and run scripts/configure_context.sh.
• scripts/configure_context.sh is the deliberate mutation path for applying explicit user-provided overrides to the active context.
• Support optional oracle.image-compartment-id only when the user explicitly provides it or when an existing context already carries it.

3. OCI CLI validation

• Validate OCI session using the profile from Fn context.
• If validation fails with a retryable security-token style error, prompt the user and retry validation with security_token auth before surfacing failure.
• Stop the flow if OCI auth remains invalid.
• Any OCI CLI nonzero exit is error unless the command succeeded and positively proved absence through an empty result.

4. Docker registry validation

• Derive registry host from Fn context registry.
• Use a live, non-mutating registry probe before claiming auth is valid.
• Treat cached Docker credentials as cached, not valid, when the registry probe cannot safely confirm them.
• If Docker auth is missing or still insufficient after the probe, prompt for OCIR credentials and run scripts/configure_context.sh --ocir-username ... --ocir-auth-token ... or an equivalent Docker login step.

5. Application selection

• Run scripts/discover_state.sh after prerequisites are valid.
• Use the Fn context compartment to list available Functions applications.
• If apps exist, explicitly ask whether to reuse an existing app or create a new one.
• If reusing, keep the selected app name/id for later deploy.
• Resolve user-selected resource names by fetching OCI JSON and comparing display-name values exactly. Never interpolate names into JMESPath expressions, and stop on duplicate exact matches instead of selecting an arbitrary resource.
• If creating, gather required details and run scripts/ensure_app.sh.
• If app_name matches an existing application but app_choice was never stated, prompt in interactive mode and fail in non-interactive mode; never silently reuse.
• Application creation supports 1-3 subnet OCIDs, optional application shape (GENERIC_X86, GENERIC_ARM, or GENERIC_X86_ARM), and opt