Add merge requst CI for checking our fixups
One of the things that is easy to get wrong during a merge request is making sure all of your changes target the correct commit with a fixup!
.
We could add a merge request CI to provide some checking.
How should we determine what is an ok target? My initial thoughts would be:
- If the commit edits, deletes or renames an existing non-mozilla file, then it should target the commit that last touched it.
- Note, if this commit is also a
!fixup
we strip them to get to the "first" target in this chain. - This should work with renames.
- Note, if this commit is also a
- If the commit adds a new file to a non-mozilla directory, then it should target the commit that last touched the directory.
- This should capture adding new assets.
- The directory would be the closest ancestor that existed before the commit. E.g. if we have existing
dirA/dirB
and we adddirA/dirB/dirC/file
, it would bedirA/dirB
. This would allow you to add a new directory.
- If the commit edits a mozilla file for the first time, there is no restriction from this file.
- In this case, I can't think of a way to determine what a correct or incorrect target would be.
- Maybe we could generate a warning instead? Not sure yet what gitlab allows, or whether we would need a bot account.
- In this case the commit could be a non-fixup.
- If the commit edits a mozilla file, that has been edited before, then it should target one of the commits that also edits it.
- Possible false passes: if we have two existing commits that target the same file, but for different reasons, then it would not determine which of these is correct. E.g.
browser/base/content/appmenu-viewcache.inc.xhtml
. - Possible false failures: if we are editing a file for some other purpose.
- Possible false passes: if we have two existing commits that target the same file, but for different reasons, then it would not determine which of these is correct. E.g.
- If the commits adds a new file to a mozilla directory, then it should target one of the commits that also edits it, or be a non-fixup.
- Similar consequences to the previous case.
Anyone have any suggestions to alter these conditions?
Are there any merge requests where you would not want this to run?