New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate FreeBSD Travis build in 2 stages #635
Conversation
67caf3c
to
21cad79
Compare
The last commit was made purely to see if FreeBSD build succeeds, it should be removed before PR is merged. |
42be77b
to
21cad79
Compare
Should be ready for review. |
Do you think it makes sense to include a hash with the image like you did in the qTox repo? So that when the build scripts change, the image is automatically rebuilt. Review status: 0 of 6 files reviewed at latest revision, all discussions resolved, some commit checks broke. Comments from Reviewable |
Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, some commit checks broke. .travis.yml, line 24 at r1 (raw file):
I think this can be removed, along with the script that does nothing? Comments from Reviewable |
Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, some commit checks broke. .travis.yml, line 24 at r1 (raw file): Previously, sudden6 wrote…
No, neither of those can be removed. Without having Comments from Reviewable |
Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, some commit checks broke. .travis.yml, line 24 at r1 (raw file): Previously, nurupo wrote…
I'm talking specifically about the Comments from Reviewable |
Don't think it would be as useful as in the qTox case, but I can add it. We don't need to rebuild the image if any of freebsd scripts are changed though, we have to watch only for changes in |
Btw, in case you are confused with how the execution flow works
|
Is |
Technically it would be called by https://github.com/nurupo/InsertProjectNameHere/blob/21cad79a9c635a05098d4da33ffd5b4acd50a858/.travis.yml#L24 because the earlier We don't want to call |
I think if you looked into what Travis calls |
Didn't know that, now it's clear. Thx for the explanation :) |
Review status: 0 of 6 files reviewed at latest revision, all discussions resolved. .travis.yml, line 24 at r1 (raw file): Previously, sudden6 wrote…
If you remove this Comments from Reviewable |
Reviewed 5 of 6 files at r1, 1 of 1 files at r2. Comments from Reviewable |
Reviewed 5 of 6 files at r1, 1 of 1 files at r2. Comments from Reviewable |
Want me to squash the commits? |
Well, I will squash them anyway. |
224c663
to
ada0ec2
Compare
There. |
ada0ec2
to
92c4108
Compare
Rebased on top of @Diadlo's |
uh, wtf happens at the windows builds? |
Oops, accidentally clicked on the wrong button while the page was still loading and layout was moving, didn't mean to close the PR. Looks like Windows tests are crashing with stack traces and don't complete fast enough triggering Travis time limit. Did this happen before? |
Windows tests are also failing in #630, but on master they succeed. |
That's really weird. They weren't failing when I LGTM'd it: https://travis-ci.org/TokTok/c-toxcore/builds/313983843 |
Actually, it's not that they succeed on master, the tests also fail there, it's just that the jobs don't exceed 50 minutes on master. The test failure is ignored in Windows builds. Those stacktraces might also be Wine bugs, the Wine on Travis must be ancient. |
I don't really understand how Windows jobs that were getting completed in 10 minutes now take over 50. The tests do fail in both cases, so the number of times tests get re-run should be the same. Also, tests get killed after certain amount of time, so there shouldn't be any infinite loop keeping them running. I'm somewhat at loss. It would help if Travis didn't truncate the logs at 4mb. |
There is this thing Travis says
but Windows jobs run in their own environment in Docker, which supposedly should be the same, so I don't think this would have affected them. |
Interesting, it looks like the job gets terminated at around 15 minutes of runtime because it outputs too much (see below), but even though Travis says that it's terminated, for some reason it keeps showing the job as running until it gets to 50 minutes.
So it looks like the reason is not in exceeding 50 minute limit but in outputting too much. |
Travis has upadted their VM image and by default the latest is being used. This has caused our Windows builds to fail due to them exceeding Travis's log limit of 4mb. It appears to be due to the new Docker version the new Trusty image has, it somehow changed network behaviour in a way that makes toxcore network module output a lot more of log messages than it used to.
bd54e23
to
e84aefe
Compare
Looks like the issue was cased by a newer Docker version on the updated Travis Trusty image. Newer Docker changed networking behaviour in a way that causes toxcore's network module spamming more log messages than it used to. For now I have just made it use older Trusty image on Travis, but the proper fix would be to somehow limit the output of the tests so that total job log doesn't exceed 4mb. |
Restarted one failing job, because it was a strange apt error. |
Yay, Travis passed. |
Reviewed 2 of 3 files at r3, 1 of 1 files at r4. Comments from Reviewable |
|
@CLAassistant is such a necromancer. |
We need to pass different argument to the FreeBSD script for stage 1 and 2 so that it could do different things in each stage. The way you would usually do this is by adding a new variable to
env
, but we can't do that because in order for two jobs to share cache they must have identicalenv
(among other things like compiler, os, etc.), so I call the scripts directly with an extra argument, as this avoid messing withenv
.This change is