Continuous Integration Strategy

Gunnar Andersson gandersson at
Fri Nov 30 12:19:20 EST 2018

Hello Everyone!

Time flies they say, and we should sometimes stop to reflect about life. 
Sometimes you forget to tell people you love them.  :( 
It's that time of the year now... when we should THINK about our nearest
friends and family, and about the not so fortunate in the world.  And about
software quality.  Because you should always think about software quality!

For that reason, I send a reminder (or clarification) about the Continuous
Integration policy for GENIVI development!

A CI "policy" is mentioned in the Quality & Maintenance policy [1] and I
have promised to write more about it before, and I already have mentioned it
many times, but in various different situations.   

Call it policy, strategy, what you will, but I want to make sure everyone is
aware of how we normally do things and recommendations for those that seek
guidance and this is for ALL the (GitHub/GENIVI) hosted projects.

More details in the Wiki, at [2], but it boils down to these 2 simple

1) For components, we use free GitHub-integrated services such as Travis-CI
(and several alternatives, if you have a special preference.)  These provide
FREE builds for all Open-Source projects, and they are good enough for quick
builds like a single component.

2) We use for large-system builds like the GENIVI
Baseline image, the GDP, SDKs and large combined systems of software, like
the SDE.  More info on Go is at [3]

The main Wiki page goes into detail about why we host the second system, and
why we recommend two different approaches (rather than for example building
the big systems in the free services).  Feel free to quote some parts in an
email to the list, if you want to discuss these things.

Now, I'm not terribly happy with the implementation of the Q&M policy by all
maintainers... You know who you are.  Probably.  You can all find a
checklist to follow at [1] so it's really easy enough.  If you cannot fulfil
some part - then just talk about it.  Send me an email, and we can document
this exception or figure out a solution.  Ask for help if you need it.

There are many things in Q&M, but for CI, some projects are missing a public
setup.  Projects might be going through CI / quality checks within
developing and adopting companies, but there should be public visibility in
an open project.  Public CI will improve the general health of the open
project, so if CI is done internally and the result can't easily be shared,
it could still *ALSO* be done with a public system.  The master branch, as
well as each proposed PR, should be tested and reported back to GitHub, not
only for GDP but for every individual "component" project that is actively

As I said, you can find more in the Wiki, see references.

Early Season's Greetings ;-)

- Gunnar

[1] Q&M Policy
[2] CI Policy
[3] Go.CD

More information about the genivi-projects mailing list