julien/apf_portal
1
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity

chore(gitlab): add MR template (ADR-0028 phase 1) #238

Merged
julien merged 1 commits from chore/gitlab-phase1-mr-template into main 2026-05-26 16:49:36 +02:00
Conversation 0 Commits 1 Files Changed 1
+30
julien commented 2026-05-26 16:42:59 +02:00
Owner
Copy Link
Copy Source

Summary

ADR-0028 Phase 1 (mirror-and-bootstrap) — repo-side groundwork for the GitLab CE migration. Phase 1 is mostly ops work on vm-gitlab (groups, mirror push, branch protection, bot account); the only artefact that needs to land in the codebase ahead of the cutover is the GitLab MR template, so that the moment Phase 2 lands .gitlab-ci.yml and developers start opening MRs, they get the same structured prompt Gitea PRs use today.

What lands

  • New file .gitlab/merge_request_templates/Default.md — port of .gitea/pull_request_template.md, content-identical except for two adjustments:
    • "PR title" → "MR title" in the comment header (GitLab terminology).
    • Typo fix: the section reference to the Conventional Commits convention was docs/development.md §5 in the original (which is "Observability dev-loop"); the correct section is §7 "Conventional commit cycle". The Gitea template still has the wrong ref — it gets deleted in Phase 3 cutover so fixing it there rather than touching it twice.

GitLab discovers .gitlab/merge_request_templates/*.md automatically; Default.md becomes the default for new MRs without any project-settings step.

Out of scope (per ADR-0028 §"Migration sequence")

Item Phase
.gitlab-ci.yml 2 (parallel pipelines)
renovate.json customManagers.fileMatch swap from .gitea/workflows/*.yml → .gitlab-ci.yml 2-3 (after .gitlab-ci.yml exists)
Remote URLs in CLAUDE.md / docs/setup/01-dev-debian-vm-setup.md §8 3 (cutover)
Deletion of .gitea/workflows/ + infra/ci-runners.compose.yml + infra/data/runner-*/ 3 (cutover)
Stale-reference sweep + signed-commit policy 4 (cleanup)

Ops checklist (executed on vm-gitlab — not part of this PR)

For traceability; the following happens outside the repo, on vm-gitlab (10.100.201.10, LAN-only — VPN for off-site access is sufficient):

  • Create project apf_portal under the existing Recherche et développement group on GitLab CE (sibling to apf-ai-service and stargate).
  • git remote add gitlab git@10.100.201.10:recherche-et-developpement/apf_portal.git && git push --mirror gitlab from a current clone.
  • Configure branch protection on main: push direct disabled, squash-merge only, status checks list left empty (peuplé en Phase 2 quand .gitlab-ci.yml apparaît).
  • Create apf-portal-bot service account on GitLab, issue a dedicated SSH/GPG signing key (cf. ADR-0028 §"Signed commits"), generate a Renovate platform token.
  • Reconfigure the existing Renovate runtime (host config, not in this repo) to add the GitLab platform endpoint pointed at 10.100.201.10. Renovate's config:recommended + the renovate.json in-repo are platform-agnostic; only the bot's host config needs the new endpoint + token.

Test plan

  • .gitlab/merge_request_templates/Default.md markdown renders identically to the Gitea template in a local preview.
  • No CI gates touched — pnpm ci:check / ci:audit unchanged.
  • On first MR opened post-mirror, the Default template appears auto-selected.

Related

  • ADR-0028 — migration ADR (accepted in #227).
  • Next: Phase 2 (gitlab-ci-pipeline) once vm-gitlab ops bootstrap is complete and the runner is registered.
## Summary [ADR-0028](../docs/decisions/0028-migrate-cicd-and-git-hosting-to-gitlab.md) Phase 1 (`mirror-and-bootstrap`) — repo-side groundwork for the GitLab CE migration. Phase 1 is mostly ops work on `vm-gitlab` (groups, mirror push, branch protection, bot account); the only artefact that needs to land in the codebase ahead of the cutover is the GitLab MR template, so that the moment Phase 2 lands `.gitlab-ci.yml` and developers start opening MRs, they get the same structured prompt Gitea PRs use today. ## What lands - **New file `.gitlab/merge_request_templates/Default.md`** — port of `.gitea/pull_request_template.md`, content-identical except for two adjustments: - "PR title" → "MR title" in the comment header (GitLab terminology). - **Typo fix:** the section reference to the Conventional Commits convention was `docs/development.md §5` in the original (which is "Observability dev-loop"); the correct section is **§7 "Conventional commit cycle"**. The Gitea template still has the wrong ref — it gets deleted in Phase 3 cutover so fixing it there rather than touching it twice. GitLab discovers `.gitlab/merge_request_templates/*.md` automatically; `Default.md` becomes the default for new MRs without any project-settings step. ## Out of scope (per [ADR-0028 §"Migration sequence"](../docs/decisions/0028-migrate-cicd-and-git-hosting-to-gitlab.md)) | Item | Phase | | --- | --- | | `.gitlab-ci.yml` | 2 (parallel pipelines) | | `renovate.json` `customManagers.fileMatch` swap from `.gitea/workflows/*.yml` → `.gitlab-ci.yml` | 2-3 (after `.gitlab-ci.yml` exists) | | Remote URLs in CLAUDE.md / `docs/setup/01-dev-debian-vm-setup.md` §8 | 3 (cutover) | | Deletion of `.gitea/workflows/` + `infra/ci-runners.compose.yml` + `infra/data/runner-*/` | 3 (cutover) | | Stale-reference sweep + signed-commit policy | 4 (cleanup) | ## Ops checklist (executed on `vm-gitlab` — not part of this PR) For traceability; the following happens outside the repo, on `vm-gitlab` (`10.100.201.10`, LAN-only — VPN for off-site access is sufficient): - [ ] Create project `apf_portal` under the existing `Recherche et développement` group on GitLab CE (sibling to `apf-ai-service` and `stargate`). - [ ] `git remote add gitlab git@10.100.201.10:recherche-et-developpement/apf_portal.git && git push --mirror gitlab` from a current clone. - [ ] Configure branch protection on `main`: push direct disabled, squash-merge only, status checks list left empty (peuplé en Phase 2 quand `.gitlab-ci.yml` apparaît). - [ ] Create `apf-portal-bot` service account on GitLab, issue a dedicated SSH/GPG signing key (cf. ADR-0028 §"Signed commits"), generate a Renovate platform token. - [ ] Reconfigure the existing Renovate runtime (host config, not in this repo) to add the GitLab platform endpoint pointed at `10.100.201.10`. Renovate's `config:recommended` + the `renovate.json` in-repo are platform-agnostic; only the bot's host config needs the new endpoint + token. ## Test plan - [x] `.gitlab/merge_request_templates/Default.md` markdown renders identically to the Gitea template in a local preview. - [x] No CI gates touched — `pnpm ci:check` / `ci:audit` unchanged. - [ ] On first MR opened post-mirror, the Default template appears auto-selected. ## Related - [ADR-0028](../docs/decisions/0028-migrate-cicd-and-git-hosting-to-gitlab.md) — migration ADR (accepted in #227). - Next: Phase 2 (`gitlab-ci-pipeline`) once `vm-gitlab` ops bootstrap is complete and the runner is registered.
julien added 1 commit 2026-05-26 16:42:59 +02:00
chore(gitlab): add MR template (ADR-0028 phase 1)
CI / commits (pull_request) Successful in 3m45s
Details
CI / scan (pull_request) Successful in 3m58s
Details
CI / check (pull_request) Successful in 4m11s
Details
CI / a11y (pull_request) Successful in 2m14s
Details
CI / perf (pull_request) Successful in 7m22s
Details
cf2ff7b231 
Port .gitea/pull_request_template.md to .gitlab/merge_request_templates/
Default.md so new GitLab MRs surface the same structured prompt once
Phase 2 lands the pipeline and developers start opening MRs.

Two content adjustments vs the Gitea original:
- PR -> MR in the comment header (GitLab terminology).
- Fixed a stale ref to docs/development.md "section 5" (Observability
  dev-loop); the Conventional Commits convention is in section 7.

Phase 1 ships repo-side artefacts only; ops bootstrap (mirror push,
groups, branch protection, bot signing keys, Renovate endpoint
reconfig) happens on vm-gitlab outside this PR per ADR-0028
section 'Migration sequence'.
julien merged commit 3191040bbc into main 2026-05-26 16:49:36 +02:00
julien deleted branch chore/gitlab-phase1-mr-template 2026-05-26 16:49:37 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adastra-bot (AdAstra Bot) julien (Julien Gautier)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: julien/apf_portal#238
Delete Branch "chore/gitlab-phase1-mr-template"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?