Richard Eisenberg writes:

Hi devs,

I recently found this text at the end of https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules :

--- The CI pipeline of ghc/ghc> applewebdata://9E3625B8-2065-48C6-A8FA-16817EA6E642/ghc/ghc includes a linting step to ensure that all submodules refer only to "persistent" commits of the upstream repositories (e.g. not wip/ branches, which may disappear in the future). Specifically, the linter checks that any submodules refer to commits that are reachable by at least one branch that doesn't begin with the prefix wip/. Consequently, you must ensure that any submodule changes introduced in a ghc/ghc> applewebdata://9E3625B8-2065-48C6-A8FA-16817EA6E642/ghc/ghc merge request are merged upstream before the merge request is added to the merge queue. ---

I don't understand what this means.

I have amended the text, hopefully clearing things up. To summarize:

- By citing "ghc/ghc>", does this mean that the linter only checks for this on branches of the ghc/ghc repo? If I have a fork (e.g. rae/ghc), are these checks disabled?

Forks run the same CI configuration as ghc/ghc and are subject to the same linter.

- Does this linter stop CI from progressing to, say, running the testsuite? If so, then how can we run the testsuite via CI if we have any submodule changes? We want to run the testsuite while the work is still in progress.

- By "you must ensure ... before the merge request is added to the merge queue": this makes me wonder whether the linter is just a warning or an error. That is, if I must ensure it, then it suggests that CI is not ensuring it.

The linter does not hold up builds for merge requests but will hold up a "pre-merge" validation job (e.g. a validation of an MR created by @marge-bot). This ensures that a patch containing a wip/ submodule reference will not be merged to master. Cheers, - Ben