Skip to content
Source
Sign inSign up

Test a change across members in CI

Your docs site builds from the docs of a library in another repository. You change both in one monorepo pull request. The CI of the docs site must build with the new library docs, before either part merges.

TanStack Source checks out the other members for you. The workflow files do not change.

1. Read the members from a part's CI

  1. Open a monorepo pull request with a part in each member that you change.
  2. In the workflow of a member, read another member at ../<folder>. For example, the docs site of acme/web reads ../docs/guide.md.

Each job of a part checks out its own repository in /workspace/repo, and the other public members next to it:

/workspace/repo/     the repository of the part (acme/web)
/workspace/docs/     acme/docs, at the head of its part
/workspace/billing/  acme/billing, at its default branch (no part)
  • A member with a part is at the head of its part. Any other member is at its default branch.
  • A private member is never checked out in the CI of another member.
  • When the head of a part in a public member moves, the other parts run their checks again with the new head.

2. Run checks for the whole monorepo

  1. Add a workflow to the monorepo's own repository, in .source/workflows/, with a pull_request or a push trigger.
  2. Open a monorepo pull request, or push to the monorepo's default branch.

Each job of the monorepo checks out every member, private members too, inside the monorepo's checkout. The layout is the same as src monorepo clone:

/workspace/repo/           the monorepo's root files
/workspace/repo/web/       acme/web
/workspace/repo/docs/      acme/docs
/workspace/repo/billing/   acme/billing
  • On a monorepo pull request, each member is at the head of its part, or at its default branch. A push to a part runs the checks again.
  • On a push to the default branch, each member is at its default branch.
  • paths filters always match on a monorepo pull request, because its change is in the members.
  • The logs follow the access of the monorepo. Only people who can read every member can read a private monorepo.

3. Make the monorepo's checks required

  1. In the monorepo's Settings, open Branch rules.
  2. Add required checks to the default branch.

A monorepo pull request then merges only when these checks passed on its latest run, for the parts as they are now. A part that moves after a passing run makes the checks wait again.

What works

  • The CI of a part sees the changes in the other public parts before anything merges.
  • The CI of the monorepo sees every member.
  • No member can use the folder repo, because each job keeps it for its own repository.
  • Each part still follows the branch rules and the required checks of its own repository.