Kanbus

Feature

Virtual projects

Mount the Kanbus projects of sibling repositories into your workspace and query all of their issues from one place, without moving any files.

When a system spans several repositories, such as a frontend, an API and a shared library, you should not have to change directories to see what needs doing. Virtual projects let one Kanbus project point at others by path. Commands like kbs list then show issues from the main project and every virtual project together, and each issue stays in the repository it belongs to.

Configure it for the team

Add a virtual_projects block to .kanbus.yml. Each entry has a label and a path, relative to the repository root, to another Kanbus project. Because the file is committed, everyone who clones the repository gets the same combined view.

project_key: app
virtual_projects:
  api:
    path: ../backend-api
  ui:
    path: ../design-system

Labels cannot match your main project_key. If a path is missing or is not a Kanbus project, commands fail with an error that names it.

Add personal projects

To see issues from a repository that is not part of the shared setup, for example a library you are linking locally, put it in .kanbus.override.yml next to .kanbus.yml. Its virtual_projects entries are added to the team's list rather than replacing it.

virtual_projects:
  my_lib:
    path: ../experimental-lib

Kanbus does not add this file to .gitignore for you. Add it yourself so your personal setup stays out of commits.

Query across projects

kbs list
kbs list --project api
kbs list --project api --status open
kbs list --full-ids

--project narrows any listing to one or more labels, and --full-ids shows the full issue keys so you can tell projects apart. The console offers the same project filter, the metrics view counts issues per project, and kbs standup rolls up one line per project by default on boards with virtual projects.

Learn more