Changes at TravisCI- affecting open source

[abdullah]

Even if we would restrict the build matrix to one linux build (averaging 40 minutes/build for estimation purposes), we would have 25 builds with 10000 credits = 1000 minutes, which will be gone before the end of the first week of January.

yikes!
This then makes the in-house Jenkins idea a lot more desirable in comparison. We just need the devops people and the resources

edit: typo

Well. Travis has been very generous with us. We could drop a request ...

... I have just dropped a request with them via support email. I cc-ed Yorik.

Let's see if this works out.

[abdullah]

I wanted to provide a short update to this topic.

Travis-CI's support reacted quite fast asking some questions about the project. I believe they are doing a fair attempt to safeguard their interests while still supporting OSS. I took the initiative, but Yorik is in CC in the exchanges with support.

At the present time, we are waiting for their consideration.

[Kunda1]

I wanted to provide a short update to this topic.

Travis-CI's support reacted quite fast asking some questions about the project. I believe they are doing a fair attempt to safeguard their interests while still supporting OSS. I took the initiative, but Yorik is in CC in the exchanges with support.

At the present time, we are waiting for their consideration.

Y'all are fantastic. Thank you!

[abdullah]

As an update, I have not received any reaction from Travis CI since 20 December. It is Christmas holidays, so uncertain times.

My expectation is that on 1 January Travis CI will stop working. We have worked before without CI, so we know how to do it. I guess a couple of weeks would be necessary to understand where we stand with Travis CI and to decide to move elsewhere or deploy Jenkins.

We should problably think of special measures for 31 December shutdown, like running the tests locally before doing a PR (that not all of us always do it, me the first one). That would at least ensure no easily detectable regressions occur.

[Kunda1]

My expectation is that on 1 January Travis CI will stop working. We have worked before without CI, so we know how to do it. I guess a couple of weeks would be necessary to understand where we stand with Travis CI and to decide to move elsewhere or deploy Jenkins.

Maybe we should start a new thread discussion on how to go about migrating to Jenkins? Core devs, any thoughts ?

[abdullah]

My expectation is that on 1 January Travis CI will stop working. We have worked before without CI, so we know how to do it. I guess a couple of weeks would be necessary to understand where we stand with Travis CI and to decide to move elsewhere or deploy Jenkins.

Maybe we should start a new thread discussion on how to go about migrating to Jenkins? Core devs, any thoughts ?

In principle Travis has indicated they would support true opensource projects. I do not think it gets more true opensource than this one. I am unsure which internal procedure they might be going through.

On one hand, if they decide to support us and we start doing the migration in the meantime, it is time and effort we lose. On the other hand we would probably like not to be without CI for a long period of time (but a couple of months should be doable).

In the past I read about "GitHub Actions" and "Azure Pipelines" being presented as "alternatives". Not sure if they support opensource or even if match our use case.

About Jenkins, I do not have hands-on experience. However, we would still need a server to run it.

Deep inside, I still have some hope that Travis CI will support us.

Somehow, given that today is 30th December, we could wait to 1 January and see if Travis.org does go to read-only or not. If it goes to read-only, the account should probably be migrated to Travis.com. Then our "10.000" credits, 1000 linux minutes will kick-in. If we continue build at the current pace, the credit will be gone within a couple of days. Then I can ask support again (probably holidays will have ended by then), and hopefully get a clear "yes" or "no" so that we can move forward one way or another.

Just my thoughts...

[sgrogan]

Just my thoughts...

Thanks for you effort on this.
We also use Travis to package the weekly builds.
We don't actual compile anything, but use Travis to set up a conda environment on the three major OS's, then package a portable build from those assets.
I guess OSX is going away no matter what.
I can do the Windows locally.
I'm setting up setting a Linux box. I have miniconda and FreeCAD working. I need to figure out how to package the AppImage from it.

[DrInfiniteExplorer]

I may be going on a tangent here, but would it not make sense to take a look at running in dockers for building?

These lines in the .travis.yml makes it look like quite a few minutes are wasted doing just toolchain install for every build.
Around 128 seconds for
* clang
* gcc-10
* gcc-7
And 72 seconds for VS15

I don't know how long it'd take to download and run a built container.
But the effort in getting containers up and running would not be wasted regardless of future path (.org, .com, custom jenkins, ...).
And IMO it'd be a good thing to separate the build environment from the CI logic.

There's an active PR in this thread with a first draft of a dockerfile for a linux environment.

[abdullah]

Short update: It appears TravisCI .org account is still running... we can keep waiting for Godot like this forever

[yorik]

Indeed it's not something crucial. We could not have CI tests at all and still be able to manage PRs. Only it's really damn useful...
Switching to some self-hosted solution requires 1) money for a server, which we should have, and 2) fair amount of work of people dedicated to set up automatic build.. Is that reasonable? Would anyone be interested in doing that?
Maybe there are online alternatives to travis too... It's hard to believe suddenly all platforms that welcomed open-source projects would disappear.. and at the same time, they do disappear all the time, so i'm not too sure where to go from there.