syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Patricelli <>
Subject Re: Reorganizing Travis CI with build stages
Date Mon, 09 Sep 2019 10:55:06 GMT
Hi Misagh,

+1 for me!

I'm not so expert of Travis, but this proposal sounds very good to me, 
mostly for the possibility to run all tests and organize better build 
sections. Several times I meet with "but works on my machine" problem :)

With the help of jobs, I would also enable console and enduser tests, 
maybe in two separate jobs. Moreover, like I'm seeing is done for CAS, 
we can enable other it tests, e.g. mysql-it, elasticsearch-it, etc. WDYT?

Best regards,

Il 09/09/19 11:37, Misagh Moayyed ha scritto:
> Hello all,
> In discussing git workflows with Francesco, I have learned that the Travis CI process
is not actually running a comprehensive set of tests and checks (such as checkstyle, etc)
that would be valuable for pull requests and contributors, possibly because such jobs take
a long time, more than what is allowed by Travis CI. I'd like to propose to reorganize the
CI build process to take advantage of the build stages feature [1]. This [2] demonstrates
an example where a given build is broken down into multiple stages, each of which has numerous
> A key thing to note in this configuration, as I understand, is that a given CI build
can have an *unlimited* number of stages, each with an unlimited number of jobs. While each
job cannot exceed a certain timeout value [3], the collective overall build stage can go on
forever in theory. Also, stages do depend on each other such that failures in one would halt
the build. A typical example would be: "Run the build, and if everything compiles, run tests,
then publish snapshots, etc".
> I think this is quite valuable for contributors who, specially, work on multiple JIRAs
at the same time. A sample workflow is to add a change, do some sanity tests and then push
to let CI run the full build suite. While it's busy kicking off the build, one could switch
to the next JIRA to repeat the same process, and as such hop back and forth between branches
and JIRAs to parallelize work activity. Ultimately, the CI is the canonical reference for
all changes and this would avoid the problem of "but it works on my machine" and of course,
saves quite a bit of time. (A full build for me takes about 20-30 minutes, if the stars align).
> How do folks feel about this proposal?
> [1]
> [2]
> [3] The good folks at Travis CI in the past have been kind enough to increase the timeout
from 50 minutes to 180 minutes and they might be willing to make the same change for syncope.
Larger tasks need to be broken down to separate jobs, of course.
> --Misagh

Dott. Andrea Patricelli
Tel. +39 3204524292

Engineer @ Tirasa S.r.l.
Viale Vittoria Colonna 97 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173

Apache Syncope PMC Member

View raw message