Are we crushing travis CI?

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
vocx
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: Are we crushing travis CI?

Post by vocx »

wandererfan wrote: Tue Mar 24, 2020 5:03 pm
carlopav wrote: Tue Mar 24, 2020 5:00 pm
So these are Draft Draft PRs? :D
Yes, there are many Draft Workbench pull requests in the queue. These are mostly ready to merge; I rebase them regularly when I think it's appropriate, that is, when there aren't many other pull requests being built. I don't think these are the issue.

And then there are Carlo's Draft Workbench Draft pull requests. Those are still work in progress.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Are we crushing travis CI?

Post by sgrogan »

The builds are actually happening https://travis-ci.org/github/FreeCAD/Fr ... hub_status they are just not showing up on the github repo.
"fight the good fight"
User avatar
wandererfan
Veteran
Posts: 6326
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Are we crushing travis CI?

Post by wandererfan »

sgrogan wrote: Tue Mar 24, 2020 9:58 pm The builds are actually happening https://travis-ci.org/github/FreeCAD/Fr ... hub_status they are just not showing up on the github repo.
Thanks for clearing that up.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Are we crushing travis CI?

Post by sgrogan »

wandererfan wrote: Tue Mar 24, 2020 10:22 pm Thanks for clearing that up.
I noticed a flurry of wandererfan-ci comments in the pull requests :D

I wonder if this has anything to do with githubs new notifications system? Does this prevent workbench maintainers from merging?
"fight the good fight"
User avatar
wandererfan
Veteran
Posts: 6326
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Are we crushing travis CI?

Post by wandererfan »

sgrogan wrote: Tue Mar 24, 2020 10:28 pm Does this prevent workbench maintainers from merging?
I just merged 3 PRs, so the mechanics seem to work the same.

OTOH, if the PR shows "waiting for Travis to complete", I leave it alone. So that certainly affects the timeliness of merging. I'll have to start checking that url you provided.
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: Are we crushing travis CI?

Post by sgrogan »

wandererfan wrote: Tue Mar 24, 2020 10:35 pm I just merged 3 PRs, so the mechanics seem to work the same.
It appears these merges aren't going thru Travis like normal https://github.com/FreeCAD/FreeCAD/commits/master for a couple of days.
The Travis notifications seem to be working on gitter. https://gitter.im/FreeCAD/FreeCAD?utm_s ... tent=badge

Maybe we need to modify our travis.yml, but DuckDuckGo hasn't provided a solution yet :(
"fight the good fight"
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Are we crushing travis CI?

Post by triplus »

The underlying issue, on why this thread has likely been opened, was reported and resolved:

https://www.traviscistatus.com/incidents/rx6fhs3wqcln

Affected PRs have been build as usual:

https://travis-ci.org/FreeCAD/FreeCAD

The problem was with the "notification part" observed on the GitHub. For new PRs the "notification part" should now again work as usual.

As for being optimal. Add [skip ci] tag to commit message more often, for example, when changing a tooltip. After FreeCAD 0.19 gets released, i plan to prepare a PR, likely including GCC/Clang 10, disabling Py2/Qt4 build job and likely disabling Clang build job for PRs. I asked in this thread, as i don't have access to this settings:

https://forum.freecadweb.org/viewtopic. ... 10#p364973

Both auto cancel options should be set to ON. For master branch that likely is the case, for PRs i have seen somebody doing a force update and then 10 builds of that PR getting scheduled, one for each commit in PR, and all getting build. That is why i assume Auto cancel pull request builds option is set to OFF, should be set ON.

Therefore in April, we will be doing two build jobs for PRs, currently four. Linux one using ccache, taking around 20 minutes and Windows one using clcache, taking around 1 h 30 min. Further massive gains, like the ones observed with fixing ccache and going from around 8 h for completing all PR build jobs, to current 2 h, would therefore be to disable Windows build job for PRs and do them only for master. But this is not technically needed ATM, Travis can still cope just fine. I have mentioned this option, as i guess it could be done, if desired.
Post Reply