travis.yml

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
sgrogan
Posts: 5632
Joined: Wed Oct 22, 2014 5:02 pm

travis.yml

Postby sgrogan » Mon Jan 20, 2020 11:24 pm

Trying to understand how we use Travis. https://github.com/FreeCAD/FreeCAD/blob ... travis.yml

Anybody know what .travis.yml#L140 and .travis.yml#L275 do, and are they related?
User avatar
kkremitzki
Posts: 1914
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: travis.yml

Postby kkremitzki » Mon Jan 20, 2020 11:30 pm

case..esac is a bash case statement. So that checks the contents of TRAVIS_OS_NAME environment variable, with switches for "linux", "osx", "windows", and a fallthrough "*".
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
blacey
Posts: 370
Joined: Tue Dec 08, 2015 11:28 pm

Re: travis.yml

Postby blacey » Tue Jan 21, 2020 2:49 am

sgrogan wrote:
Mon Jan 20, 2020 11:24 pm
Anybody know what .travis.yml#L140
Travis 140 is yaml block notation. It basically means that all statements following the -| at a given indentation level are considered a single block hence it is a method for grouping several logically-connected shell script statements into a single execution block so to speak. Logic that spans multiple bash statements (e.g. if/then/else) either needs to use block notation or be encapsulated in a script. Travis "executes" each "-" statement individually checking the exit status to determine if the build should continue or not. So, in the case of a block, there is a single exit code for the statement that represents a block.

Does this make sense?
User avatar
sgrogan
Posts: 5632
Joined: Wed Oct 22, 2014 5:02 pm

Re: travis.yml

Postby sgrogan » Wed Jan 22, 2020 12:58 am

kkremitzki wrote:
Mon Jan 20, 2020 11:30 pm
case..esac is a bash case statement.
blacey wrote:
Tue Jan 21, 2020 2:49 am
Does this make sense?
Thank you both.
User avatar
sgrogan
Posts: 5632
Joined: Wed Oct 22, 2014 5:02 pm

Re: travis.yml

Postby sgrogan » Wed Jan 22, 2020 1:49 am

Next Questions;

1) As far as I can tell ccache doesn't support MSVC, so we use clcache. That means anything ccache in the windows blocks is not doing anything?

2) For the linux gcc builds, it seems we install all the packages we need for QT4/PY2 and QT5/PY3, there should be a way to split this. Nested case statements? Has anyone tried to split this? Maybe this also effects the cache, I don't think so but maybe. The cache is not working for the gcc builds.
blacey
Posts: 370
Joined: Tue Dec 08, 2015 11:28 pm

Re: travis.yml

Postby blacey » Wed Jan 22, 2020 2:43 am

sgrogan wrote:
Wed Jan 22, 2020 1:49 am
1) As far as I can tell ccache doesn't support MSVC, so we use clcache. That means anything ccache in the windows blocks is not doing anything?
Not sure, you probably want to ask @abdullahtahiriyo because he added the Windows ccache environment variables https://github.com/FreeCAD/FreeCAD/comm ... c0c1756ef0
sgrogan wrote:
Wed Jan 22, 2020 1:49 am
2) For the linux gcc builds, it seems we install all the packages we need for QT4/PY2 and QT5/PY3, there should be a way to split this. Nested case statements? Has anyone tried to split this? Maybe this also effects the cache, I don't think so but maybe. The cache is not working for the gcc builds.
AFAIK the Linux packages on Travis install very quickly because they cache them locally within their infrastructure so I'm not sure how much time splitting them out would actually save. The PYTHON_MAJOR_VERSION is set to 3 vs. 2 for the respective Linux builds so that environment variable could be used to only install the python2 or python3 dependencies accordingly.
triplus
Posts: 9277
Joined: Mon Dec 12, 2011 4:45 pm

Re: travis.yml

Postby triplus » Fri Jan 24, 2020 5:06 am

As we haven't yet resolved GCC caching issue i created this PR. The matrix contains only a single job (Linux/GCC) and lets see how it will behave.
triplus
Posts: 9277
Joined: Mon Dec 12, 2011 4:45 pm

Re: travis.yml

Postby triplus » Fri Jan 24, 2020 11:17 pm

OK therefore other build jobs likely don't have an affect on GCC caching as i have build the PR twice and no changes detected in build time. There is an interesting thing involved as currently the build takes around 2h 15min and a month back i remember it was just under 3h. Anybody on our side did anything about that (build or code vise)?

Anyway, we i guess will need to understand ccache in-depth to resolve this issue and i already started investigating. Will use current PR for testing purposes. One thing i don't have access to is this page:

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

Is there anything special listed there?
User avatar
sgrogan
Posts: 5632
Joined: Wed Oct 22, 2014 5:02 pm

Re: travis.yml

Postby sgrogan » Fri Jan 24, 2020 11:43 pm

triplus wrote:
Fri Jan 24, 2020 11:17 pm
Is there anything special listed there?
Looks like this:
Capture.PNG
Capture.PNG (56.11 KiB) Viewed 446 times
triplus wrote:
Fri Jan 24, 2020 11:17 pm
Anybody on our side did anything about that (build or code vise)?
The cache is smaller, I think most of the reduction was due to your work with the Libpack.
triplus
Posts: 9277
Joined: Mon Dec 12, 2011 4:45 pm

Re: travis.yml

Postby triplus » Sat Jan 25, 2020 8:44 pm

OK now a minimal Linux GCC oriented travis.yml is a part of the 2930 pull request and i can extract some useful info from the logs. In addition i applied some ccache oriented toolchain related tweaks. Can you delete the cache for PR.2930 on Travis? After i will wait for this issue to get fixed upstream and will rebuild the PR twice. To see what happens. Hopefully this will increase:

Code: Select all

cache hit rate                      0.07 %