modifying-builtin-plugins

Builds and provisions built-in Golem plugins with descriptor-driven registry-service embedding.

1.5k|212|Updated Nov 24, 2023
One-click install
npx skills add https://github.com/golemcloud/golem --skill modifying-builtin-plugins
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: modifying-builtin-plugins
Source: https://github.com/golemcloud/golem/tree/main/.agents/skills/modifying-builtin-plugins
Command: npx skills add https://github.com/golemcloud/golem --skill modifying-builtin-plugins

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Modifying Golem's built-in plugins requires coordinating plugin source code, committed WASM binaries, descriptor metadata, and registry-service provisioning logic, and mistakes in any of these steps cause startup failures or stale embedded binaries.

Core Features & Use Cases

  • Plugin Source and SDK Guidance: Preserves the correct async oplog processor API, imports, and export macros when editing plugins like the OTLP exporter.
  • Build and Validation Workflow: Runs cargo make build-plugins and wasm-tools validation, ensuring the committed WASM exists, is non-empty, and reflects source changes.
  • Descriptor-Driven Provisioning: Keeps plugin metadata in BuiltinPluginDescriptor/BUILTIN_PLUGINS rather than config, CLI, or environment variables, with idempotent registration and environment grants.
  • Use Case: When updating the OTLP exporter plugin, use this Skill to rebuild the WASM, bump the descriptor version, verify registry-service compilation, and run the authoritative integration tests.

Quick Start

Rebuild the OTLP exporter plugin, validate its committed WASM, and verify the registry-service provisioning changes compile and pass integration tests.

Frequently Asked Questions about modifying-builtin-plugins

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

FAQPage Schema
How do I rebuild Golem built-in plugins after source changes?

Run cargo make build-plugins, which uses cargo-make's CARGO_MAKE_CRATE_TARGET_DIRECTORY, then validate the output with wasm-tools validate --features all. Confirm the copied WASM exists, is non-empty, and changed relative to your source edits, then commit it since the registry service embeds it with include_bytes at compile time.

Where should built-in plugin metadata live in Golem?

Plugin metadata and embedded bytes belong in BuiltinPluginDescriptor and the BUILTIN_PLUGINS table in golem-registry-service, not in BuiltinPluginsConfig, bootstrap code, CLI flags, or environment variables. The config struct is only the Enabled/Disabled switch.

When do I need to bump the built-in plugin descriptor version?

Bump the descriptor version when publishing a distinct plugin version. If only the provisioning logic changes and the plugin itself is unchanged, the WASM does not need to be rebuilt or the version bumped.

How does built-in plugin provisioning work at registry-service startup?

When enabled, startup creates or finds the built-in owner's system app and environment, hash-updates descriptor components, deploys the environment once, then idempotently registers each descriptor. New environments transactionally receive undeletable grants for all built-in plugins, but existing environments are not backfilled.

Which tests verify built-in plugin changes in Golem?

Run plugin-local Rust checks from plugins/<plugin>/, cargo make build-plugins with WASM validation after source or manifest changes, cargo check -p golem-registry-service after descriptor changes, and cargo make integration-tests-group7 for authoritative coverage. Tests spawning Cargo or Golem subprocesses belong only in the CLI integration suite.