Products and repositories
How Bilbis groups your code. Products hold shared automation settings; repositories are the actual codebases.
Short answer
A product is a group of related repositories that share automation settings. A repository is one codebase, registered inside a product.
Both exist because real teams have more than one repo, and most teams want to set automation rules once instead of on every repo individually.
How it works
You create a product in Products and give it a name. Inside that product you register one or more repositories - your GitLab projects or GitHub repos.
Settings flow like this:
| Setting | Where it lives | What it covers |
|---|---|---|
| Branch prefixes, MR labels, preferred engine, approval timeout, auto-merge | Product | Defaults for every repo under this product. |
Provider path (e.g., org/repo-name), default branch, stack hints, per-repo command overrides | Repository | Things specific to one codebase. |
| Jira config | Product (with org-wide fallback) | Per-product override of the org-wide Jira mapping. |
| Webhooks | Product | Trigger labels for incoming GitLab/GitHub webhooks. |
When you create a pipeline, you pick a repository. Bilbis reads the product's defaults and the repo's overrides to figure out how to run.
When to create a new product vs a new repo
- New repository when the codebase is new but the automation rules from an existing product fit. Example: a sister microservice that should follow the same review and merge pattern.
- New product when the automation rules differ. Example: an experimental codebase you want to dispatch with a smaller engine and looser approval rules than your main product.
A repo lives in exactly one product. To move a repo, edit it inside its current product or recreate it under another.
Identity
| Field | Meaning |
|---|---|
| Product slug | Short URL-safe identifier for the product. |
| Repository slug | Short user-friendly identifier for the repo. Used in the Pipelines form, the pipeline detail page header, and timelines. |
| Repository UUID | Internal id Bilbis uses for joins. Most surfaces show the slug; the UUID appears in tooltips and in the audit log. |
| Provider path | The org/repo path on GitLab or GitHub. |
Pipelines reference repos by slug. If you change a slug after pipelines have run on it, past pipelines keep their old slug; new pipelines use the new one.
Where you see it in Bilbis
- Products - the list page. Click in to see a product's repos and shared settings.
- Products → <product> - repo list, edit dialog, Jira override card, webhook card.
- Products → <product> → <repo> - the per-repo edit dialog.
- New pipeline form → Repository - pick a repo (or pick several with Let Bilbis pick).
- Pipeline detail header → Product / Repo - which product and repo this pipeline is running on.
Permissions
| Action | Who can do it |
|---|---|
| Create a product | Admin or owner. |
| Edit a product | Admin or owner. |
| Add a repo | Admin or owner. |
| See products and repos | Any role. |
Related pages
- Products - full field reference for creating and editing a product.
- Repositories - full field reference for adding a repo.
- Jira - org-wide and per-product Jira configuration.
- Webhooks - per-product webhook setup.
- Create a pipeline - repos are picked here.