Publish extensions

What a compatible release includes

A release contains the installable plugin ZIP plus the files a compatible registry source needs:

• The plugin ZIP built and validated with Shopware CLI.
• SHA256SUMS for independent package verification.
• extension-mesh-release.json for release history.
• extension-mesh-registry.json for direct discovery.

Before you start

Your repository should contain a plugin at its root with:

• type: shopware-platform-plugin in composer.json.
• A semantic version in composer.json.
• require.shopware/core and require.php constraints.
• extra.shopware-plugin-class pointing to the plugin class.
• Built Administration assets or source files that Shopware CLI can build.

Choose a publishing path

Path A: use the complete release workflow

Choose this when changing composer.json should build, validate and publish the plugin without any other release orchestration. Create .github/workflows/publish-extension.yml:

name: Publish extension

on:
  push:
    branches:
      - main
    paths:
      - composer.json
      - .github/workflows/publish-extension.yml

permissions: {}

jobs:
  publish:
    permissions:
      contents: write
      id-token: write
      attestations: write
    uses: Extension-Mesh/shopware-publisher/.github/workflows/publish.yml@v0.1.0-alpha.1

The publisher is maintained separately in Extension-Mesh/shopware-publisher . It is versioned independently from the Shopware connector. Keep it pinned to a reviewed reference and update that reference deliberately.

Path B: add it to an existing release job

Keep your existing triggers, tests and versioning. Replace only the step that creates the GitHub Release with the composite publisher action:

permissions:
  contents: write
  id-token: write
  attestations: write

steps:
  - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
    with:
      fetch-depth: 0

  - name: Publish with ExtensionMesh metadata
    uses: Extension-Mesh/shopware-publisher@v0.1.0-alpha.1
    env:
      EXTENSION_MESH_TAG: ${{ github.ref_name }}

The action derives the repository information from composer.json, builds and validates the plugin, creates the release and updates the stable registry channel. Run it for a semantic version tag such as v1.2.3. Do not create the same GitHub Release in an earlier step—the publisher deliberately refuses to modify an existing release that has no ExtensionMesh metadata.

Path C: publish a ZIP you already verified

If an earlier job already produced the installable archive, download that artifact and pass its path to the action. The publisher validates its packaged composer.json, adds the required release information and publishes the supplied ZIP byte-for-byte:

- name: Publish the verified archive
  uses: Extension-Mesh/shopware-publisher@1355c834bb904a01205ff46cc16a81461c3ce4b6
  with:
    source-archive: ${{ runner.temp }}/verified/MyPlugin.zip
  env:
    EXTENSION_MESH_TAG: ${{ github.ref_name }}

The archive must contain <TechnicalName>/composer.json, and that Composer version must match the tag. This is the smallest integration for repositories that want to keep their existing build and verification flow while adding the checksum, manifests and stable repository channel ExtensionMesh needs.

Publish a new version

Set a new release version in composer.json and push the change to main. The workflow creates the matching v<version> tag automatically.

The workflow creates the GitHub Release and updates the generated extension-mesh-registry branch. Do not create that release or edit the generated branch manually. When the workflow completes, verify that all four release assets are present and that the ZIP contains the expected plugin root.

When adding the workflow to a repository with existing releases, publish it together with a new plugin version. Existing releases without ExtensionMesh metadata are not modified.

Connect an installation

A Shopware 6.7 test installation can add the repository URL directly:

https://github.com/owner/plugin-repository

The connector resolves the repository to the generated registry channel:

https://raw.githubusercontent.com/owner/plugin-repository/extension-mesh-registry/extension-mesh-registry.json

Every successful release updates this document, including prereleases. Consumers therefore keep the repository URL while published versions change.

Prove the update path

1. Install the first release in the isolated test installation.
2. Change the plugin version and make a small, observable plugin change.
3. Push the second version through composer.json.
4. Refresh registries in the target installation.
5. Run the update and verify the new version and behavior.

A successful first installation is not enough. The second release proves that packaging, release history, compatibility selection and the platform update lifecycle agree.

Creator beta checklist

• The workflow builds assets before packaging the release.
• The generated ZIP passes Shopware CLI validation.
• The checksum matches the public ZIP.
• The repository or exact registry URL loads without manual metadata edits.
• Incompatible Shopware or PHP versions are not offered.
• A second release appears as an update and installs successfully.
• Release failures leave no misleading published version behind.

The canonical workflow is documented in the publisher repository . Report reproducible publishing problems in its issue tracker .

Continue with the registry model or the beta validation checklist.