Continuous integration

smif ci is the recommended release entry point for repositories that selected GitHub Actions during smif init. It refuses to run outside GitHub Actions and skips branches other than the configured base branch.

smif ci

When changesets are present

On the base branch, ci computes the version operation, renders the configured release branch, commit message, and pull request title, applies the version files, force-updates that branch, and creates or refreshes its pull request back to the base branch. The commit message and pull request title both default to chore(release): bump versions; optionally customize them under [release] with the same strict release.* context used by the branch template.

The rendered release branch must differ from the base branch. Semifold checks this before applying version files or changing Git refs; using the base branch as the release branch is rejected rather than treated as a trunk-release workflow.

Contributors therefore only need to commit a changeset with their code and merge that pull request. Maintainers review versions and changelogs in the generated release pull request.

Release pull request bodies normally include each package's changelog. If the body exceeds a conservative 65,536 UTF-8 byte budget, Semifold replaces it with a package version summary and a notice directing reviewers to the pull request's Files changed tab for the complete changelogs. The summary includes only complete package entries that fit the budget, in package ID order. Changelog files remain complete. This protection applies both when creating and when updating the pull request; no configuration is required.

When no changesets remain

After the release pull request is merged, the next base-branch run sees no pending changesets and calls the publish operation with GitHub Release handling enabled. Packages are checked and published in dependency order.

1. 01Code and changeset reach the base branch
   →
2. 02Automation maintains the release pull request
   →
3. 03The release pull request returns to the base branch
   →
4. 04Packages publish in dependency order

Environment and outputs

The command relies on GITHUB_ACTIONS, GITHUB_REF_NAME, GITHUB_REPOSITORY, and GITHUB_TOKEN. The generated workflow uses the stable step ID semifold. The branch that actually runs writes either the semifold-version or semifold-publish step output key, and the job maps them to version and publish:

jobs:
  release:
    outputs:
      version: ${{ steps.semifold.outputs['semifold-version'] }}
      publish: ${{ steps.semifold.outputs['semifold-publish'] }}
    steps:
      - id: semifold
        run: smif ci

Downstream jobs read needs.release.outputs.version or needs.release.outputs.publish. The branch that did not run produces an empty string. On a partial publish failure, Semifold tries to write publish JSON with recovery states before returning a non-zero status.

--dry-run prepares the selected branch behavior without pushing a branch, creating a pull request, or publishing. Use the generated workflow as the supported baseline instead of reconstructing permissions from a minimal snippet.

GitHub error diagnostics

GitHub failures identify the operation and include the HTTP status, API message, validation details, and documentation link when available. Client failures include their underlying error chain. These details do not require --debug; GitHub tokens are redacted. A 403 includes permission checks appropriate to the operation, without assuming that permissions are the only possible cause.

Release pull request queries, creation, updates, and branch push failures stop the command. When ci selects publishing, it uses the same Release and asset diagnostics as publish.