arch-toolkit

CI and Release

This page explains how the ecosystem master-only release flow is enforced by GitHub Actions.

Pull Request Validation

Every repository has a branch policy workflow.

PR opened or updated
        |
        v
Branch Policy
        |
        +-- base master -> head must be feature/*, fix/*, bugfix/*, config/*,
                            docs/*, chore/*, dependabot/*, release/x.y.0[-rcN],
                            or hotfix/x.y.z[-rcN]

The branch policy runs before expensive build work. It keeps repository history aligned with the release model.

Master Gate

Pull requests into master use the normal development and release gate:

branch policy -> lint -> build -> tests -> coverage -> docs -> affected samples

release/* and hotfix/* branches are publication candidates. Other branch types are normal code, docs, dependency, or repository maintenance changes and do not publish artifacts.

Automatic Tagging

When a release or hotfix PR is merged into master, CI reads the source branch name:

release/2.0.0      -> 2.0.0
release/2.0.0-rc1  -> 2.0.0-rc1
hotfix/2.0.1       -> 2.0.1
hotfix/2.0.1-rc1   -> 2.0.1-rc1

The release workflow creates the annotated tag from that version.

The tag name does not use a v prefix.

Artifact Flow

The main release path is a single CI run after the PR merge:

merge into master
        |
        v
resolve version from branch
        |
        v
write the explicit version file
        |
        v
verify build and quality gates
        |
        v
publish artifacts
        |
        v
push tag
        |
        v
create GitHub Release

The tag-triggered workflow is not part of this path, which prevents duplicate publication. Gradle receives the resolved version explicitly, and the remote tag is pushed only after every publisher succeeds.

Release Recovery

The master release workflow supports manual recovery after its workflow fix has reached master. The operator must provide both the original release/* or hotfix/* branch name and the exact master commit SHA. CI validates an existing tag against that commit, reuses it when correct, and rejects it when it points elsewhere.

Repository Differences

The branch and version rules are shared. Build and publication commands stay repository-specific.

Repository	Release verification	Publication
`arch-toolkit`	module assemble matrix	Maven Central per publishable module
`arch-android`	`./gradlew ciBuild`	`ciPublishMavenCentral`, `ciPublishGithubPackages`
`arch-event-observer`	`./gradlew ciBuild`	`ciPublishMavenCentral`, `ciPublishGithubPackages`
`arch-lumber`	`./gradlew build`, `:lumber:koverVerify`	Maven Central and GitHub Packages tasks

Tag Workflow Fallback

Repositories may keep a manually dispatched release workflow as an escape hatch. It must not react to the tag pushed by the automatic master merge flow, otherwise both workflows can publish the same version concurrently.

The normal path is still:

release/hotfix PR -> master -> tag + publish in the same workflow

This site is open source. Improve this page.