mirror of https://github.com/apache/superset.git synced 2026-05-22 08:15:36 +00:00

Files

Claude Code cbcfd9599f docs: cut 6.1.0 versions for docs, admin_docs, developer_docs, components

Snapshots all four versioned Docusaurus sections at v6.1.0. Built on
top of the version-cutting tooling work in chore/docs-cut-6.1.0-versions
so the snapshot benefits from:

- Auto-gen refresh before snapshotting (database pages from engine
  spec metadata, API reference from openapi.json, component pages
  from Storybook stories) — captured at the SHA we cut from rather
  than whatever happened to be on disk.
- Data-import freeze: country list, feature flag table, database
  diagnostics, and component metadata are copied into snapshot-local
  `_versioned_data/` dirs so the historical version doesn't silently
  mutate when the source files change.
- Depth-aware import-path rewriter that handles deeply-nested
  component MDX files referencing `../../../src/` from the snapshot.

Versioning behavior: `lastVersion` stays at `current` for every
section, so the canonical URLs (`/docs/...`, `/admin-docs/...`,
`/developer-docs/...`, `/components/...`) continue to render content
from master. The `current` version is consistently labeled "Next"
with an `unreleased` banner, and `6.1.0` is a historical pin
accessible only via its explicit version segment.

Component playground: previously `disabled: true` in versions-config.json,
now enabled and versioned. The plugin block in docusaurus.config.ts
was already gated only by the `disabled` flag, so no other code
changes were needed to bring it back online.

The frozen `databases.json` in the snapshot is the canonical 80-database
artifact from the latest committed state in master (preserved by the
generator's input-hash cache), not a fallback regenerated from a
local Flask environment.

2026-05-13 17:15:46 -07:00

2.1 KiB

Raw Blame History

title, sidebar_position

title	sidebar_position
Deployment	7

Deployment

Once an extension has been developed, the deployment process involves packaging and uploading it to the host application.

Packaging is handled by the superset-extensions bundle command, which:

Builds frontend assets using Webpack (with Module Federation configuration).
Collects backend Python source files and all necessary resources.
Generates a manifest.json with build-time metadata, including the contents of extension.json and references to built assets.
Packages everything into a .supx file (a zip archive with a specific structure required by Superset).

To deploy an extension, place the .supx file in the extensions directory configured via EXTENSIONS_PATH in your superset_config.py:

EXTENSIONS_PATH = "/path/to/extensions"

During application startup, Superset automatically discovers and loads all .supx files from this directory:

Scans the configured directory for .supx files.
Validates each file is a properly formatted zip archive.
Extracts and validates the extension manifest and metadata.
Loads the extension, making it available for use.

This file-based approach simplifies deployment in containerized environments and enables version control of extensions alongside infrastructure configuration.

2.1 KiB Raw Blame History

Deployment

2.1 KiB

Raw Blame History