Considering a naming convention and workflow that guarantees back-linking to issues/merge-requests/epics
Problem
With !67 (merged) we now are able to auto-include links towards issues, merge requests, and epics if we name our files correctly + have the commit hook installed (one-time manual action).
Our naming convention at https://gitlab.com/gitlab-org/gitlab-design/blob/master/CONTRIBUTING.md#naming does take this into account, but we have no way of semi-enforcing ourselves to work in single a or multiple files per issue/merge request/epic kind of way
Our current process is prone to mistakes which obstruct transparency as in informing issues/merge requests/epics of progress via design files
Proposal
- Testing commits on following naming convention for design files on push + communicate what is preventing the push and how to fix that
- CI test for checking commit messages on including a link towards their respective issue/merge request/epic + communicate why the pipeline is failing and how to fix that (this way people who are not using the commit hooks yet).
What does success look like?
- We are only able to push design files which meet our naming convention and have their commit message body be populated with correct links.
- We are made aware if we are not using the commit hooks
- We are readily provided with the information to resolve those errors
As a final result we will have more transparency in every issue/merge request/epic for which we have a design file(s), thus relying less on the individual folder structure every designer uses.
@pedroms (your merge request !67 (merged) inspired me to this issue