Skip to content

Repository files navigation

bamr87/.github — shared automation & release methodology

This repository is the single source of truth for CI, 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.

The methodology in one picture

Conventional Commits ──► CI gate (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.yml detects the stack and pushes to the right registry.
  • Quality is gatedci.yml blocks merges on tests, lint, build, docs, commit-lint, and CodeQL.

Reusable workflows

WorkflowPurposeCall it with
ci.ymlMerge-to-main gate (detect → test/lint/build/docs/commitlint/codeql)uses: bamr87/.github/.github/workflows/ci.yml@main
release-please.ymlVersion bump + CHANGELOG + GitHub Releaseuses: bamr87/.github/.github/workflows/release-please.yml@main
publish.ymlPublish to gem / npm / PyPI / GHCR + attach assetsuses: bamr87/.github/.github/workflows/publish.yml@main

Composite action: detect-stack — emits node/ruby/gem/python/jekyll/mkdocs/docker booleans + the primary registry.

Toolchain versions come from repository variables

ci.yml resolves each language version as caller input → the calling repo's vars.* → a built-in default:

VariableDefault
NODE_VERSION20
PYTHON_VERSION3.12
RUBY_VERSION3.3

The middle rung is the point: bamr87 is a personal account, so GitHub's org-level variables don't exist. The dash declares the canonical values once in _data/fleet.yml (in bamr87/bamr87) and projects them onto every repo with dash config sync --apply, so a version bump reaches the whole fleet without editing ~40 workflows. Pass an explicit input only when one repo genuinely needs to differ.

Two gates, deliberately

This ci.yml runs six jobs including a CodeQL matrix — the right gate for release-grade repos. The dash also publishes a one-job gate, bamr87/bamr87/.github/workflows/standard-ci.yml, for experimental and content repos. They are not redundant: making every repo pay for the fuller gate would multiply per-push runner count ~6× across the fleet. Pick by tier (_data/standards.yml).

Adopt the standard in a repo

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 two caller workflows from workflow-templates/ into .github/workflows/ and add a release-please config:

.github/workflows/ci.yml # → ci.yml@main
.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>"}

release-type by ecosystem

Ecosystemrelease-typeVersion source release-please maintains
Ruby gemrubyversion-file (e.g. lib/<gem>/version.rb); other files via extra-files
Node / TSnodepackage.json
Pythonpythonpyproject.toml (+ __init__.py via extra-files)
Jekyll / bash / docs (no package)simplea VERSION file → GitHub Release only

Required secrets / setup

Publishing only runs when the ecosystem is detected and its credential exists; otherwise the version bump, changelog, and GitHub Release still succeed.

RegistryCredentialNotes
RubyGemsRUBYGEMS_API_KEY (repo secret)
npmNPM_TOKEN (repo secret)published with provenance
PyPInonetrusted publishing (OIDC) — configure the publisher on PyPI
GHCRnoneuses the built-in GITHUB_TOKEN
CI on the release PRRELEASE_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.

About

Shared CI/release automation (reusable workflows, release-please, publish) + community health files for all bamr87 repos

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors