travis: Add a Travis CI settings file

[b4n]

Although I'd rather have a continuous integration setup on our own (like next to git.geany.org), I'm afraid we don't really have time to set it up nor probably resources to run it on almost everything.

So, maybe Travis CI is not so bad -- though although it doesn't say so anywhere, I don't know if it comes with strings attached. Anyway, here is a .travis.yml that seems to work great. If we agree on it, we can merge and then enable the repository in Travis CI.

[b4n]

BTW, I didn't enable using Clang because I believe GCC is solid enough to report our errors and that having a set or fatal errors is harder if we have several compilers, but if you feel like we should have it should mostly just work (and create 2 more jobs).

[elextr]

[EDIT] Forgot to say great idea.

Don't think the open source part has strings attached.

We can play with clang after it works for gcc, useful for BSD and OSX users.

But far more important is the passing button for the github front page http://docs.travis-ci.com/user/status-images/ :)

BTW why isn't it using the full b4n-pedantic settings?

[b4n]

We can play with clang after it works for gcc, useful for BSD and OSX users.

I honestly doubt anything we would use has any risk of breaking at the compiler level, but I don't mind much, it just wastes (or not) some CPU time on Travis CI -- unless our flags break it, so we need to have different flags depending on the compiler, which while doable is a bit more annoying.

BTW why isn't it using the full b4n-pedantic settings?

Because my settings do output a few warnings (about non-literal format strings and non-constant string literals mostly -- but worse with GTK2 that has some crap in its headers), and that any non-fatal warning is useless anyway.
I could add them, but we need to only error on things we never wanna see, it's not like the developers would see the warnings and decide whether or not to fix them -- basically I'm saying that we can't afford false-positive here.

[elextr]

basically I'm saying that we can't afford false-positive here.

Ok, makes sense.

[techee]

After the yesterday's sad sed behaviour I thought it might be interesting to enable osx travis builds so the slightly strange cmdline tools used by osx are testable by others as well. In addition we'd get clang build as a bonus.

However, the osx builds have to be enabled by an email request to travis:

http://docs.travis-ci.com/user/multi-os/#Manual-intervention-required

[eht16]

👍
Completely forgot to mention, I like the idea and are willing to help where I can.

[codebrainz]

Needs mingw support. I think the package is called mingw-w64 and the ./configure script needs to have --host=i686-w64-mingw32 added to it.

[b4n]

Needs mingw support. […]

If we all are happy with Travis, I'll try to do that, should be easy enough

[codebrainz]

I'm happy with it. The only other one I've used is Jenkins, which seems more powerful but requires own server and has a pretty terrible user-interface (at least the version I used before).

[b4n]

(just rebased on current master, no changes yet)

[b4n]

BTW, we should also add this to geany-plugins

[elextr]

👍

[eht16]

@b4n do you mean geany/geany-plugins#172? :)

[b4n]

@b4n do you mean geany/geany-plugins#172? :)

Oh, forgot about that :)

[b4n]

Okay, I'm trying to get cross build to work but I get strange errors when I try installing the mingw packages, any idea? https://travis-ci.org/b4n/geany/jobs/69443746

[b4n]

okay, maybe it was a conflict with mingw32 packages. Anyway, now it seems to be building at least, we'll see how it goes

[b4n]

wowow! both mingw builds passed!

So, it works. I'm not very fond of the bundle fetching, as it hits gnome.org on every builds… got a better idea?

[codebrainz]

I see no harm in this PR at all. @b4n maybe you should make a "geany" account on Travis CI?

[b4n]

@codebrainz good point, geany account opened there

[b4n]

I just squashed all mingw commits together. No changes, except removing 1 outdated comment.

[eht16]

wowow! both mingw builds passed!

Yeah, awesome job!

So, it works. I'm not very fond of the bundle fetching, as it hits gnome.org on every builds… got a better idea?

What exactly are you bothering about?
We could host the bundles ourselves to ensure they are always available
regardless of what happens on gnome.org. Or do you have other concerns?

[b4n]

What exactly are you bothering about?

I'm probably just being crazy nice, but the load on their part -- e.g. I wonder how nice it is for us to hit their servers that often. But I guess it really doesn't matter for anyone (and it might be worse for everyone if we hosted them ourselves, if we're limited in bandwidth as we probably got less money there than they do).

[b4n]

BTW, also for GTK3, their bundles are old, and I don't know if we can download msys2 ones from the net easily?

[b4n]

BTW, apart that I think it can be merged as is, as it works and doesn't look too crazy

[eht16]

Ok got it. I don't think downloading the bundles from our server would result in any problems like bandwidth or load. But it still keeps the load on the Travis CI servers.
Is there any way of keeping some kind of persistent data between builds, maybe some kind of cache or so?

[b4n]

Ok got it. I don't think downloading the bundles from our server would result in any problems like bandwidth or load.

Good. But do you think it's useful? I'm probably just being overly worried on loading others (which probably are actually here for that).

But it still keeps the load on the Travis CI servers.

This I don't think it's an issue -- and I care a lot less, too :)
They provide build machines and download packages anyway, so I doubt the additional load here is any issue for them. And while I have nothing against them, in the contrary, they got a clear business model so I'm not really worried in using some of their bandwidth.

Is there any way of keeping some kind of persistent data between builds, maybe some kind of cache or so?

Well, yes and no, see http://docs.travis-ci.com/user/caching/
IIUC, we could if we paid, or if we were using a newer solution that don't allow for installing packages from APT.

[b4n]

hehe, look at the status of this PR ;)

[b4n]

IIUC, we could if we paid, or if we were using a newer solution that don't allow for installing packages from APT.

Hold that, they seem to have very recently changed some things, that maybe be possible now. See http://docs.travis-ci.com/user/migrating-from-legacy/

[b4n]

Hold that, they seem to have very recently changed some things, that maybe be possible now. See http://docs.travis-ci.com/user/migrating-from-legacy/

Well, no, it's not yet possible for us: https://travis-ci.org/b4n/geany/jobs/70455778#L77
But in time we might.

Edit: BTW, I made a typo in the GTK packages, those are OK. We miss intltool, and optionally python-docutils and rst2pdf.

[b4n]

So again, unless we want to change the GTK bundle URLs for MinGW builds, I think this can be merged.

We can update the Travis build method later too, it's not written in stone.

[codebrainz]

IIUC, we could if we paid

If anyone else was curious. Too expensive.

PR looks fine to me.

[eht16]

Ok, I guess intltool should be easy to get on the whitelist as it is a common package. Probably similar for python-docutils. I'd be more afraid of G-P later on where we have way more dependencies. But this is not a problem for now.

Can we affect the build frequency in any way? Something like "build on every commit/push but only if last build is older than X minutes/hours"?

Just thinking loudly:
in the future we could maybe even use the build result to provide Windows binaries for download, as we do it now for our nightly builds. But this would involve uploading the binaries from Travis CI to our infrastructure in some secure way, which might not be easy except we want anyone be able to upload stuff to our servers :).
But this is not part of this PR, just a thought for the future.

I'm going to merge this now. And later on, we can probably solve the caching/load problem.

[b4n]

I'd be more afraid of G-P later on where we have way more dependencies.

Indeed. But that's only the new container-based infrastructure (which has cache, yeah…), without we can install anything we want.

Can we affect the build frequency in any way? Something like "build on every commit/push but only if last build is older than X minutes/hours"?

Not that I know of, AFAIK it will build every push and this can't be changed. But I might be wrong.
Though, the point of Travis is to test the repo, so skipping a test seem a bit weird. Or do you mean delay it and perform a bulk a little later?

Just thinking loudly:
in the future we could maybe even use the build result to provide Windows binaries for download, as we do it now for our nightly builds. But this would involve uploading the binaries from Travis CI to our infrastructure in some secure way, which might not be easy except we want anyone be able to upload stuff to our servers :).

Travis seem to have some kind of way to have secure data (not sure how, probably based on user tokens), so it might be possible.

[eht16]

Can we affect the build frequency in any way? Something like "build on every commit/push but only if last build is older than X minutes/hours"?

Not that I know of, AFAIK it will build every push and this can't be changed. But I might be wrong.
Though, the point of Travis is to test the repo, so skipping a test seem a bit weird. Or do you mean delay it and perform a bulk a little later?

I was actually thinking of some kind of delay.
Sure, skipping pushes in a CI setup doesn't make much sense. But I think
in our case, delaying builds and so sort of combining pushes into one
build is still reasonable, as long as the delay is not too high.
Anyway, if not possible, no need to discuss further.

Just thinking loudly:
in the future we could maybe even use the build result to provide Windows binaries for download, as we do it now for our nightly builds. But this would involve uploading the binaries from Travis CI to our infrastructure in some secure way, which might not be easy except we want anyone be able to upload stuff to our servers :).

Travis seem to have some kind of way to have secure data (not sure how, probably based on user tokens), so it might be possible.

Sounds promising. I'll have a look at some point.

[elextr]

Enrico, stop worrying, we have so few PRs and dependencies that Travis is unlikely to notice, think of something like Julia with a huge mass of deps a massive compile and build and test and a dozen or so PRs per day.