# Enforce repo workflow and ownership

# discussion

currently @tim-hm control's merges into both mainline branches (dev and main). this creates a bottleneck, reduces repo ownership and reduces engineer responsibility.

the aim of this issue is to facilitate engineer ownership and increase velocity for all work up to and including the dev branch.

as code committed into a mainline branch is automatically deployed, @luke.whittington and @tim-hm will retain ownership of the `main` branch / production environment workflow.

i've listed the tasks below which should be applied to every repo in the glimpse namespace. the lead for each repo is responsible for making these changes and merging them into **their** 🥳 `dev` branch after an appropriate peer approval.

on account privileges, currently there is a mix of Maintainer and Developer levels across all accounts. All accounts will be set to Maintainer to apply these changes, and once completed all accounts will be downgraded to Developer. This should hopefully provide some protection from unintentional changes.

# tasks

- [ ] update repos
- [ ] ensure there is a main and dev branch, and the dev branch is the 'default' in settings > repository > default branch
- [ ] settings > general > merge requests
- [ ] encourage squashes
- [ ] require that all discussions are resolved
- [ ] settings > general > merge request approvals
- [ ] Any eligible user should be set to 1
- [ ] Enabled "Require new approvals when new commits are added to MR"
- [ ] Enabled "Prevent MR approvals by the author"
- [ ] settings > general > repository settings > protected branches
- [ ] protect the dev branch with:
- allowed to merge: developers + maintainers
- allowed to push: maintainers
- allowed to force push: enabled
- require approval from code owners: enabled
- [ ] protect the main branch with:
- allowed to merge: luke and tim
- allowed to push: luke and tim
- allowed to force push: enabled
- require approval from code owners: enabled
- [ ] add a CODEOWNERS file. ideally there is one owner, but in the case of commons/core its ok for multiple owners for now. more information about the structure of the CODEOWNERS file can be found [here](https://docs.gitlab.com/ee/user/project/code_owners.html). keep the CODEOWNERS file at the repo root

# new flow

active changes are done in a working branch. when changes are ready for merging:

1. squash commits to an appropriate number - aim to keep groups of changes in a single commit if possible
2. switch to dev, pull, switch to working branch and rebase the working branch off of dev
3. submit a MR and assign the MR to someone to review
4. when the reviewer is happy Approve the MR and reassign to the author (this might require changes which require re-squashing and re-basing)
5. codeowner merges. the merge must be a fast forward commit, if its not, then double check that the branch was rebased correctly otherwise our commit history will not be linear.

# owners

| Repo | Owner |
| --------- | -------- |
| glimpse.* | @name(s) |
| glimpse.messageboard | @samueldobbie |
| glimpse.vault.ads.ephemeral | @samueldobbie |
| glimpse.vault.ads.attribution | @samueldobbie |
| glimpse.vault.ads.events | @samueldobbie |
| glimpse.frontend.ui | @mountEvarus |
| glimpse.frontend.integrations | @eddieyu1998 |
| glimpse.frontend.prebid | @eddieyu1998 |
| glimpse.devops.* | @luke.whittington
| glimpse.vault.core | @marah_jaber |
| glimpse.vault.ads.serving | @marah_jaber |
| glimpse.ads.advertiser | @violeta_co |
| glimpse.ads.publisher | @violeta_co|