On Fri, Aug 21, 2020 at 06:33:20PM -0700, Kevin J. McCarthy wrote: > > That would be fine with me, *but* I'd rather the CI not fail because of a > trivial linting issue. So "loose" as you mention below would be good.
I was thinking on a check that runs in CI against PRs, so the author would have a chance to fix anything that fails. But I'd argue that the point is for the check to fail (on an incoming PR), so that it can get tidied up _before_ getting merged. > > I'm not super familiar with gitlab CI, though may be possible to do some > > things in there, and I think Travis and Circle are also typically free > > for open source. It might require some effort to unify the standards of > > certain scripts / programs, but might be worth the effort? > > There is a .gitlab-ci.yml file in the Mutt source tree. The "build:" part > is run after every push. You can see right now it just runs prepare and > then make. We could just invoke the scripts directly there, but it would be > better to have a make target, I think. Maybe a separate step called "check" for one or more of these? Do all steps run with the same executor, or can 'image' be set to a different one for a given check? Is the 'check_sec.sh' script run in CI too? If it's called when building the release, this seems like another good lightweight one to check in CI if it's not there already. > I wasn't sure if you were volunteering to dig into it, or just bringing the > idea up. If the former, I would be happy to create the Makefile changes if > you have suggestions on tools and their invocations. A little of both; if there's interest, I'm happy to try and dig into a little when I've got time - but would probably need some good code review to make sure some of the requested changes will be portable enough. I'll make any code changes in separate commits from the CI changes themselves for easier review. /w
