GitHub

Creates a release on GitHub. If a Markdown changelog is present, this target reads the release name and description from it.

Configuration

Option	Description
`tagPrefix`	Prefix for new git tags (e.g., `v`). Empty by default.
`previewReleases`	Automatically detect and create preview releases. Default: `true`
`tagOnly`	Only create a tag (without a GitHub release). Default: `false`
`floatingTags`	List of floating tags to create/update. Supports `{major}`, `{minor}`, `{patch}` placeholders.

Environment Variables

Name	Description
`GITHUB_TOKEN`	Personal GitHub API token (create one)

Example

targets:
  - name: github
    tagPrefix: v
    previewReleases: true

Floating Tags

Use floatingTags to maintain “latest major version” tags that always point to the most recent release:

targets:
  - name: github
    floatingTags:
      - "v{major}"        # Creates v2 for version 2.15.0
      - "v{major}.{minor}" # Creates v2.15 for version 2.15.0

This is useful for users who want to pin to a major version while automatically receiving updates.

Monorepo: independently-versioned products

The tagPrefix option lets a single repository host several independently-versioned products by namespacing their git tags — for example cli@1.2.3 and mcp@2.0.0. Craft honors the prefix on both the write side (the tag it creates) and the read side (latest-tag detection, changelog base, and CalVer scans are all scoped to the prefix), so the products don’t cross-contaminate each other’s version history.

Today, each product is configured with its own github target declaring its tagPrefix and a matching releaseBranchPrefix (so release branches don’t collide). A common layout is one .craft.yml per product:

# .craft.yml for the CLI product
github:
  owner: getsentry
  repo: toolkit
releaseBranchPrefix: release/cli
targets:
  - name: github
    tagPrefix: "cli@"

# .craft.yml for the MCP product
github:
  owner: getsentry
  repo: toolkit
releaseBranchPrefix: release/mcp
targets:
  - name: github
    tagPrefix: "mcp@"

Releasing 1.2.3 for each product then produces the tags cli@1.2.3 / mcp@1.2.3 on release branches release/cli/1.2.3 / release/mcp/1.2.3 — no collisions.

Release Workspaces

Use top-level workspaces: to define independently versioned release units in one repository. Keys may be literal paths or glob patterns, and Craft expands patterns to concrete directories relative to .craft.yml. Select one concrete path explicitly with --workspace <path> or CRAFT_WORKSPACE:

minVersion: 2.29.0
github:
  owner: getsentry
  repo: toolkit
workspaces:
  packages/*:
    releaseBranchPrefix: release/cli
    targets:
      - name: github
        tagPrefix: "cli@"
  tools/mcp:
    releaseBranchPrefix: release/mcp
    targets:
      - name: github
        tagPrefix: "mcp@"

Selected workspace paths use nonempty ASCII path segments containing letters, digits, periods, underscores, and hyphens. Segments cannot be ., .., __proto__, or start with -. They are release units, not npm package workspaces. Craft ignores files matched by a configured glob and rejects overlapping workspace keys. A workspace cannot use github.projectPath, and a workflow cannot provide both a path and a workspace. This keeps each publish request unambiguous.

The craft workspace list command prints the concrete workspace paths as a JSON array for automation. Action publish titles always carry the full concrete path.

Preview Releases

If previewReleases is true (default), releases containing pre-release identifiers like alpha, beta, rc, etc. are marked as pre-releases on GitHub.