Shared reusable GitHub Actions workflows, release-please setup and community health files for every bamr87 repo.
This repository is the single source of truth for versioning and releases across every bamr87 repository. It hosts reusable GitHub Actions workflows, composite actions, workflow templates, and the default community-health files that every repo inherits.
It is consumed by the bamr87 dash — the monorepo that vendors all the projects as submodules.
Conventional Commits ──► CI gate (standard-ci.yml) ──► merge to main
│
▼
release-please opens a "release PR"
(bumps version file + CHANGELOG.md)
│
reviewer merges the release PR
│
▼
tag vX.Y.Z + GitHub Release ──► publish.yml
(gem / npm / PyPI / GHCR)
- Versioning & changelog are automated by release-please:
commit messages drive the semver bump and the
CHANGELOG.md. No manual version edits. - Releases are reviewable — every release is a PR you can inspect before it ships.
- Publishing is ecosystem-aware — one
publish.ymldetects the stack and pushes to the right registry. - Quality is gated by the shared CI gate, which lives in the dash:
bamr87/bamr87/.github/workflows/standard-ci.yml(stack-detected lint, test and build).
| Workflow | Purpose | Call it with |
|---|---|---|
release-please.yml |
Version bump + CHANGELOG + GitHub Release | uses: bamr87/.github/.github/workflows/release-please.yml@main |
publish.yml |
Publish to gem / npm / PyPI / GHCR + attach assets | uses: bamr87/.github/.github/workflows/publish.yml@main |
Composite action: detect-stack — emits node/ruby/gem/python/jekyll/mkdocs/docker booleans + the primary registry.
This repo used to host a six-job reusable gate, ci.yml (detect → test/lint/build/docs/commitlint/CodeQL), plus a workflow-templates/ci.yml caller for it. Nothing called it: on 2026-10-03 the workflow files of all bamr87, year-of-ai and ai-world-view repos were listed and none referenced it, while 19 repos call the dash's standard-ci.yml. It was removed to leave one shared gate. Recover it from git history if a fuller gate is wanted again.
The fastest path is the dash's rollout tool (from the monorepo root):
tools/adopt-release.sh <repo> # or the /adopt-release Claude command…which scaffolds the files below. To do it by hand, copy the release caller from workflow-templates/ and the CI caller from the dash's templates/standard-ci/ci.yml into .github/workflows/, and add a release-please config:
.github/workflows/ci.yml # → bamr87/bamr87 standard-ci.yml
.github/workflows/release.yml # → release-please.yml@main, then publish.yml@main
release-please-config.json # release-type: ruby | node | python | simple
.release-please-manifest.json # {".": "<current version>"}
| Ecosystem | release-type |
Version source release-please maintains |
|---|---|---|
| Ruby gem | ruby |
version-file (e.g. lib/<gem>/version.rb); other files via extra-files |
| Node / TS | node |
package.json |
| Python | python |
pyproject.toml (+ __init__.py via extra-files) |
| Jekyll / bash / docs (no package) | simple |
a VERSION file → GitHub Release only |
Publishing only runs when the ecosystem is detected and its credential exists; otherwise the version bump, changelog, and GitHub Release still succeed.
| Registry | Credential | Notes |
|---|---|---|
| RubyGems | RUBYGEMS_API_KEY (repo secret) |
|
| npm | NPM_TOKEN (repo secret) |
published with provenance |
| PyPI | none | trusted publishing (OIDC) — configure the publisher on PyPI |
| GHCR | none | uses the built-in GITHUB_TOKEN |
| CI on the release PR | RELEASE_PLEASE_TOKEN (optional PAT) |
so the release PR triggers CI; falls back to GITHUB_TOKEN |
Branch protection (require the CI checks before merge) is opt-in via the monorepo's tools/protect-branch.sh.
See docs/RELEASES.md in the monorepo for the full guide.
| Path | What it is |
|---|---|
.github/workflows/ |
Reusable workflows called by other repos: release-please.yml and publish.yml |
workflow-templates/ |
Starter release.yml offered in the Actions tab of every bamr87 repo |
CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md |
Default community health files inherited by repos that do not define their own |
There is no build step or test suite here. A change to a reusable workflow affects every repo that calls it, so try it from one consumer repo before merging.
Contributions are welcome via pull request. Use Conventional Commits and keep the CI checks green. See CONTRIBUTING.md for the workflow.
Notable changes are recorded in CHANGELOG.md; the full record is in the commit history. Tagged versions are on the releases page.
Released under the MIT License.
Part of the bamr87 portfolio — browse every project on Amr's GitHub profile.