## Problem Dependency Scanning auto-remediation builds its commit message in [`build_commit_message`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/dependency_management/security_update/create_merge_request_service.rb#L184). The subject is always `Update <package names>`, followed by `<name>: <old> → <new>` lines, a two-line "automatically generated" note, then `Vulnerability: <advisory title>` and `Severity: <severity>`. The MR title is a separate string, `Security: Update <name> from <old> to <new>`. Projects that enforce Conventional Commits reject this. The AI Gateway project (ai-assist) runs commitlint in a `lint:commit` job. The bot MR [!7171](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/7171) fails [that job](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/jobs/16833484951) with `subject-empty` and `type-empty`, so it cannot merge even after a maintainer approves it. This was [reported in the feedback issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/600511#note_3929653989). The reporter [replied](https://gitlab.com/gitlab-org/gitlab/-/work_items/600511#note_3933375862) that they want both the commit message and the MR title fixed. That is the right scope. ai-assist squashes on merge, so the MR title becomes the commit subject on the default branch. Fixing only our commit message would still land `Security: Update fast-uri from 3.0.6 to 3.1.8` there. Projects can also enforce an MR title regex as a mergeability check, which our title can fail too. The commit is created in the monolith through `Files::MultiService`, not by dependabot, so we control the whole message and the title. Dependabot's own prefix detection does not apply here, and there is no setting to change either format today. ## Proposal Detect the convention the way Renovate and Dependabot do, and use one string for the commit subject and the MR title. - Renovate, with [`semanticCommits: "auto"`](https://docs.renovatebot.com/semantic-commits/), detects Conventional Commits from recent commits and uses `chore(deps): update dependency X to vY`. Its PR title is derived from the commit subject. In gitlab-org, [gitlab-ui !5173](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/5173) is titled `chore(deps): update dependency dompurify to v3.2.6` and its commit is identical. The gitlab project does not use Conventional Commits, so the same bot produces plain `Update dependency ... to v...` there ([!254621](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254621)). - Dependabot's detection is in [`PrNamePrefixer`](https://github.com/dependabot/dependabot-core/blob/main/common/lib/dependabot/pull_request_creator/pr_name_prefixer.rb). It looks at recent commits, excluding its own and merge commits. If at least 30% use Angular/Conventional prefixes (build, chore, ci, docs, feat, fix, perf, refactor, style, test), it uses `<type>(<scope>): `. The type is `chore` if recent commits use `chore` and never `build`, otherwise `build`. The scope is `deps`, or `deps-dev` when only dev dependencies change. It matches the repo's capitalisation after the colon, and security fixes get a `[security]` or `[Security]` marker after the prefix. PR title and commit subject come from the same string. Proposed approach: port Dependabot's detection rules (30% threshold, `chore` vs `build`, capitalisation) instead of inventing our own, so the output matches what users of either tool expect. The same subject goes into the commit and the MR title, for example `chore(deps): update fast-uri from 3.0.6 to 3.1.8`. When no convention is detected, keep the current format. No new configuration or UI. In ai-assist, all 18 of the last non-merge commits on the default branch match `type(scope): ...`. Two constraints: - commitlint's `config-conventional` errors on body lines over 100 characters. The `Vulnerability:` line is already about 95 characters for the fast-uri advisory, so longer titles would fail even with a correct prefix. Wrap body lines at 100 in both formats. - The title and the commit subject must come from the same string, but the title is also parsed. [`SINGLE_DEPENDENCY_REGEX`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/dependency_management/security_update/merge_request_title.rb#L8) matches `Security: Update X from A to B`, and [`RemediationDismissalChecker`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/dependency_management/security_update/remediation_dismissal_checker.rb#L35) uses it on existing MR titles for dismissal matching. Parsing has to accept both the old format (existing open and closed MRs) and the new one, for example `chore(deps): update X from A to B`. The grouped title `Security: Update N dependencies` needs a conventional equivalent too. Every format must still carry the name and target version. Out of scope, for product follow-up: always using Conventional Commits, or making the prefix or template configurable in the scan profile. ## Implementation plan 1. Add a detector that fetches about 20 recent commits on the default branch through `project.repository.commits` (one Gitaly call per MR creation), drops merge commits and bot-authored ones, and returns the type (`chore` or `build`), the scope (`deps`) and the capitalisation, or nil, following Dependabot's rules. 2. Make `MergeRequestTitle` build either format and make parsing accept both, so dismissal matching keeps working for MRs that already have the old title. 3. Use one subject for both the commit (`build_commit_message`) and the MR title (`build_mr_title`), including the title refresh when an MR is updated to a newer version. 4. Wrap body lines at 100 characters in both formats. 5. Add specs for a conventional history, a plain history, a history of only merge commits, an over-long advisory title, and dismissal matching against both the old and new title formats. ## Workaround Affected projects can ignore these commits in `commitlint.config.js`: ```js ignores: [(msg) => msg.includes('automatically generated by GitLab Dependency Management')] ``` This only covers the bot's own commit. It does not help when the project squashes on merge, because the squash commit is built from the MR title.