travis.yml

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!
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

travis.yml

Post by sgrogan »

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?
"fight the good fight"
User avatar
kkremitzki
Veteran
Posts: 2511
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

Re: travis.yml

Post by kkremitzki »

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

Post by blacey »

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
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: travis.yml

Post by sgrogan »

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.
"fight the good fight"
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: travis.yml

Post by sgrogan »

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.
"fight the good fight"
blacey
Posts: 370
Joined: Tue Dec 08, 2015 11:28 pm

Re: travis.yml

Post by blacey »

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
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: travis.yml

Post by triplus »

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
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: travis.yml

Post by triplus »

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
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: travis.yml

Post by sgrogan »

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 1777 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.
"fight the good fight"
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: travis.yml

Post by triplus »

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 %
Post Reply