On Sat, Nov 21, 2020 at 3:32 PM Waldek Hebisch <[email protected]> wrote: > > On Sat, Nov 21, 2020 at 10:56:17PM +0800, Qian Yun wrote: > > We have a discussion about Travis CI 3 years ago, now we have > > moved to GitHub, I believe now it's time to have CI? > > > > One point Waldek raised was "run test before commit". > > > > If we have CI support, and you commit in your own master repo > > before merge into main repo, you can "run test before commit". > > > > For pull request, with CI we can run tests before commit. > > > > Even if we commit directly into repo, with CI we can find > > problems more quickly. > > > > (Anyway, I assume we don't run a full build and full test > > before commit, most of time, right? :-) > > I do run full build and full testsuite before almost every > commit.
Do you say that you expect every contribution to be wrapped up in exactly one commit? (This is not very usual, although there are workflows where this is a requirement, e.g. https://en.wikipedia.org/wiki/Gerrit_(software) - used at Google, AFAIK is built around such a model) > I sometime make exception when change is obvious > and and does not change code and I am goind to do another > commit with full build and full testsuite run just after > current commit. I expect other people to do the same > (those rules appeared here several times and should be > well known). This may look extreme but: > - project that use more relaxed rules freqently have > non-buildable repository and this would be bad > - IME before commit test from time to time catches problems > (fails). Catching/correcting them later would cause > more trouble. In danger to state the obvious (to me): the idea of CI is that *you* only look at a contribution after it passes pre-defined automatic tests, and these are as extensive (and possibly much more extensive, as it can be done on many different platforms (i.e. OS+LISP) at the same time) as *you* would do by hand. It is meant to save *you* time. And avoid SNAFUs such as "oops, it's already merged, but it does not work on FooOS with BarCL". > > > So, if we all agree to add CI support, I'll post a simple > > CI script for discussion, and we can add functionality > > gradually over time. > > Well, more testing is better than less. Just I do not > consider CI as game changer. > > -- > Waldek Hebisch > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20201121153211.GA1000%40math.uni.wroc.pl. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq1cxr3HLZwqP3DgmvkR2GnKCg4jZVY%2Bf0cS0OhRZeUJMQ%40mail.gmail.com.
