travis.yml
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
travis.yml
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?
Anybody know what .travis.yml#L140 and .travis.yml#L275 do, and are they related?
"fight the good fight"
- kkremitzki
- Veteran
- Posts: 2515
- Joined: Thu Mar 03, 2016 9:52 pm
- Location: Illinois
Re: travis.yml
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 "*".
Re: travis.yml
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?
Re: travis.yml
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.
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"
Re: travis.yml
Not sure, you probably want to ask @abdullahtahiriyo because he added the Windows ccache environment variables https://github.com/FreeCAD/FreeCAD/comm ... c0c1756ef0
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.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.
Re: travis.yml
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.
Re: travis.yml
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?
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?
Re: travis.yml
Looks like this:
The cache is smaller, I think most of the reduction was due to your work with the Libpack.
"fight the good fight"
Re: travis.yml
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 %