[WORK-AROUND] [MSVC2017 Windows] Building succeeds as a PR, but fails when in master

Environments Windows
1

Hi!

I am building a c++ solution (FreeCAD) using MSVC2017 in Windows with clcache.

This works just fine when I do a pull request.

However, when I merge the pull request into master, the build will fail.

** Problem description**

Inside my travis.yml I have this code:

if [ "${TRAVIS_OS_NAME}" == "windows" ]; then
        cmd.exe /C 'C:\Users\travis\build\FreeCAD\FreeCAD\.travis\build.bat'
        ...
else
        ...
fi

build.bat contains this script:

echo on

call "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" amd64 

MSBuild.exe FreeCAD_Trunk.sln /p:CLToolExe=clcache.exe /p:TrackFileAccess=false /p:CLToolPath=C:\Users\travis\build\FreeCAD\FreeCAD /m:2 /nologo /verbosity:minimal /p:Configuration=Release /p:Platform=x64

When I push to my personal branch and do a pull request, this code works just fine (I cancelled the script after msbuild.exe starts building):

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

After merging the PR to master:
https://travis-ci.org/FreeCAD/FreeCAD/jobs/527373677

MSBuild does not start building, it hangs within the batch file between the sourcing of the environment variables and the execution of msbuild.exe with error

C:\Users\travis\build\FreeCAD\FreeCAD\build>call "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" amd64  
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

Before using the batch file, I was using this one liner inside travis.yml instead of the call to the batch file:

cmd.exe /C '"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" amd64 && MSBuild.exe FreeCAD_Trunk.sln /p:CLToolExe=clcache.exe /p:TrackFileAccess=false /p:CLToolPath=C:\Users\travis\build\FreeCAD\FreeCAD /m:2 /nologo /verbosity:minimal /p:Configuration=Release /p:Platform=x64'

The behaviour was the same. Working perfectly when in a PR. Failing in master.

I cannot understand what is different during the PR build and the master build. I have read that some variables are not available during PR for security reasons, but I do not follow what may be happening.

I would appreciate any help.

Regards,
abdullah

Full Configuration:

Travis:
https://travis-ci.org/FreeCAD/FreeCAD/jobs/527373677/config

Source (batch file):

2

Yesterday I managed to find a work-around, to use filter_secrets:

   - os: windows
        language: cpp
        filter_secrets: false
        env:
          - CMAKE_OPTS="-DBUILD_FEM_NETGEN=ON -DFREECAD_RELEASE_PDB=OFF"
          - GENERATOR="Visual Studio 15 2017 Win64"
          - PYTHON_MAJOR_VERSION=3        
          - MSBUILD_PATH="c:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin"
          - TEST_PATH="C:\Users\travis\build\FreeCAD\FreeCAD\build\bin"
          - CLCACHE_PATH="C:\Users\travis\build\FreeCAD\FreeCAD\"
          - VS15=true
          - CCACHE_TEMPDIR=/tmp/.ccache-temp
          - CCACHE_COMPRESS=1
          - CCACHE_DIR=$HOME/.ccache
          # enable this if clcache extended log is needed
          #- CLCACHE_LOG=1
        cache:
          directories:
            - $HOME/clcache

Hypothesis of what is happening:

Apparently, the execution of the batch file is affected by the secrets filter that Travis CI uses to protect “secrets”, such as deployment variables.

When a PR is run, the build environment is protected from access to those variables as per design. However, when master is build, the filter mechanism is applied to the output, thereby interfering with the batch file execution, halting the output to stdout and triggering a timeout.

Security concerns:

I am by far no security expert. Using the secrets_filter as above, it only applies to “Windows” builds. There is no output of any of this information to the console. I do not see a risk (other that somebody else with access to master inadvertently echoing their contents to the console after the filter is set to false).

My current full configuration, just in case it may help anybody else is:

P.S.: Somewhat unrelated, I wanted to add that using clcache in our project brings down build time from over 2 hours to around 50 minutes.