Our company uses a fairly standard multirepo setup: each repo in our gitlab.com group is a service, deployed via CI pipelines.
We need to track user-observable changes: feature requests, bug reports. Currently, we track those as issues. Each of them typically requires code changes to multiple repos, e.g. to a service and to its caller API.
Whenever we plan a release, we spend a long time tracking down which projects are ready and what features the release corresponds to.
The issue page shows related merge requests: open/merged/closed status, MR title, project, number, and pipeline status. Pretty great!
The merge request page for each of these shows which environments it was deployed to. Also great!
But we’d like a summary of these deploys on the issue page itself, so we can track status at a glance.
We have considered:
- Add labels (manually or automatically) to issues depending on MR status. This doesn’t capture the details well enough to be useful.
- File a feature request to show impacted environments on in the related merge requests widget.
- Add a label (manually or automatically) to MRs on deploy, and file a feature request to show labels in the related merge requests widget.
- Edit MR title (automatically) on deploy. Not very readable and messes with parts of our pipelines that read MR titles, but mostly ok.
- Add a layer of indirection, e.g. track business-level features as epics and repo-level changes as issues. The linked issues widget does show labels, so this sort of works, but requires a lot of bookkeeping pipeline steps that’ll be tedious to maintain.
- Roll our own tool calling the Gitlab API, not integrated with the web UI (unless we make it a browser add-on).
Is there a better way? If not, which of these is most viable?