Richard Eisenberg <r...@richarde.dev> writes: >> On Jan 27, 2020, at 8:19 PM, Ben Gamari <b...@smart-cactus.org> wrote: >> >> 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. > > Very interesting! Are there other such checks? I always assume that if > an MR passes CI, then it is suitable for merging. Of course, what you > describe makes perfect sense here -- we don't require upstream to have > our commits during CI, but we do during merging. I'm just wondering if > there are other such scenarios that are checked for. > Indeed we run a whole suite of linters in the `lint` stage of the CI pipeline. See, for instance, [1]. These linters generally fall into a few categories:
* Some (e.g. the submodule and changelog linters) enforce policy that would otherwise be mere social convention. The former we already discussed. The latter checks that the string TBD doesn't appear in core library changelogs, ensuring that we take the necessary steps to finalize the changelogs before cutting a release. * Some (e.g. the makefile, CPP, and shellcheck linters) check for portability issues that we may not otherwise stumble upon in the set of platforms that we routinely test * Some (e.g. the typecheck-testsuite and lint-testsuite linters) are simply cheaper checks for obvious mistakes that we would otherwise catch stumble upon late in the build. Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
