Investigate if Travis could be used to test build pelux-manifests

[DunderRoffe]

Currently the CI system is not accessible from outside. This means that developers that do not have access to the CI system can not se the error logs when a pull-request fails.

Since Travis-ci is free for open-source projects, maybe it could be used instead of the current closed setup for pelux-manifests.

[socec]

Definitely, it is easy to use and you can have a nice badge on the project page :)

[breakreturn]

@socec Have you tried it before? I thought one would run into issues with how much time jobs can take. And I guess we are talking about building an image here right?

[socec]

@breakreturn I have used it personally but on a small project, never had to worry about build time. But you are right, open source plan for Travis does impose a time limit. Is there a way to store build cache on an http server so it can be used to speed up the build?

[frznlogic]

Maximum build time on travis is 10 minutes AFAIK. This is according to @jonte maybe a year ago?

[jonte]

@frznlogic Yeah, build time is limited in the free version, but you can pay for more time I think.

[jeremiah]

What about using an Amazon EWS or Google Cloud instance for building?

[jonte]

@jeremiah We've tried Amazon EC2 for building with Vagrant, and that works pretty well. Crazy expensive though. I managed to create quite a bill in only a few days. My main problem was that it is difficult to properly terminate building in case of errors in a reasonable time frame. On a "real" machine, this is less of a problem, on EC2, it'll cost a lot of money. This could probably be fixed with some time invested..

[breakreturn]

@jeremiah @jonte I'm currently trying to find out if we can get support to have a build cache on some publicly accessible machine to reduce build times. If we can do that, it might increase our options in this question as well.

[erikboto]

I think it is a good idea to have a build cache publicly accessible, but we can't rely on that this is always usable. At times there will be modifications to e.g. the toolchain which will render the cache useless, and then the CI system needs to be able to build everything from scratch.

[breakreturn]

@erikboto Yeah that's true. I guess we should investigate "open CI" with the worst-case scenario in mind, i.e. a full rebuild from scratch etc.

[socec]

Whatever we choose, we must be able to do a clean build at any given time. Using the build cache is a way to save resources (money/time) most of the time when things are going well.

[jeremiah]

So it seems like a CI system that can build both locally and remotely?

Google has a free three month trial of their cloud services: https://cloud.google.com/free-trial/ Perhaps we test that for cost and usability and then we have some evidence to show management that we think it is a cost effective investment (or not as the case may be.)

[rpannek]

Now we have gotten servers from Luxoft Cloud for that and they are set up and running. They will be made accessible from the internet once we set up the triggers, etc. correctly.

[DunderRoffe]

@rpannek are the Jenkins servers online and accessible now? If so I think we can close this issue.

[rpannek]

They are online and accessible but we don't link to them from the website which we perhaps should? But for that we might need to think about the licenses for the binaries? What do you think @jeremiah?

[jeremiah]

We should have "complete and corresponding" licenses for each built image in the build/tmp/deploy dir. If we publish that along with the image we should be fine.

[tobsan]

This point is sorta moot since we now have an accessible Jenkins instance up and running. Can I close it?

[DunderRoffe]

I think you can

[rpannek]

Yep, as #won't fix or something.

[jeremiah]

Closing as "won't fix" per discussion.