# Continuous integration Run the generated GitHub Actions release-PR or publish branch behavior from one command. Source: https://semifold.noctisynth.org/docs/commands/ci/ Language: en `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. ```bash smif ci ``` ## When changesets are present [#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 [#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. ## Environment and outputs [#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`: ```yaml 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-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`.