Current known issues — Please read this before posting a new topic

Would love to know the current status of the secrets issue too


Have a funny feeling that Windows Defender play a role in yarn/npm install being really slow. Is it enabled? and if so, is yarn and npm cache added to the exclusion list?

Without secret keys, how would I deploy stuff to AWS S3 without announcing my secret id and key to the world?


Secrets env keys are a huge blocker for us as well. :frowning:


Is there a way to run without the secret only for the Windows build? I have a code coverage token in my environment, but I only need that for a Linux build anyway.

Any eta for the secrets issue? It will help a lot to understand when to plan work to dedicate to Travis


Secrets-Are-Killing-Windows Current Summary


:point_right: :point_right: If you have a secure variable, Windows will hang.

In other words, a Travis CI encrypted environment variable in .travis.yml OR an environment variable in the Travis CI UI that doesn’t have “Display value in build log” checked, will cause a Windows job to hang.

Fix Schedule

Travis CI staff have not provided any estimate for a fix. In Oct. 2018, @josh said “we are working to address this.” Also, here. That’s the latest mention of a fix.


You can add filter_secrets: false to your .travis.yml but, according to @dominic, this risks revealing your secrets.

For example, suppose this is your .travis.yml:

    - os: windows
      language: sh
      filter_secrets: false
        - echo $super_secret_password

In the job log, you’ll see your $super_secret_password in the clear. Without filter_secrets: false, you would instead see [secure].

You can also allow failures for Windows builds and hope that at some point it will not be necessary:

    - os: windows
    - stage: test
      python: 3.7
      dist: xenial
    - stage: test
      os: windows
      language: sh
      python: 3.7

Topics Relating to the Issue

  1. Windows Instances Hanging Before Install
  2. Choco install hangs forever
  3. Perl support on Windows
  4. Docker Windows containers on Windows
  5. Windows job stopped because of sudden no output
  6. Node.js build fails with no obvious error
  7. Build log appears to be incomplete for failed build
  8. Travis hangs after worker information
  9. Unexpected windows job failure
  10. "choco install" fails instantly with no output or reported error code, no indication of what's wrong
  11. Windows CI not starting
  12. Windows builds failing when using env vars
  13. Uknow error. Windows build

Thank you for the very detailed and collected response! Unfortunately, I don’t have any news to share yet on this front, but I’m seeing what can be shared in terms of progress and issues we’ve ran into to provide some greater visibility. :slight_smile:


Awesome overview of the issue @YakDriver! Thank you!

Regarding filter_secrets: false, a recommendation would be to set it only on the Windows job when testing on multiple OSes e.g.

  - linux
  - osx

    - os: windows
      filter_secrets: false

I am checking in to also report that I believe the Windows Secret build issue is a problem. Specifically, the windows build will not begin running anything and will terminate after 10 minutes. I am opposed to putting it into the “allowed failures” section, or exposing API secrets, or using “travis_wait”.

Left unaddressed, this represents a serious case of normalization of deviance and can hide more serious issues that only arise on windows builds. Please consider fixing this bug a priority. Thank you.

If there is a workaround that can cause windows to build without exposing the API secret, please post it here.


@BanzaiMan I’ve experienced a lot of issues and slow builds on windows, and it seems that most of them are caused by Windows Defender. Is it possible to turn off Windows Defender Realtime Monitoring on startup / add stuff to the WD exclusion sets, even before cloning the repository? Yarn install and installing yarn itself fails/is really slow when WD is enabled. I’ve been using something similar to the script below, which cuts off 12+ min on the yarn install. Everything else is also more reliable.

export NODEPATH=$(where.exe node.exe)
export PROJECTDIR=$(pwd)
export YARNCACHE=$(yarn cache dir)

powershell Add-MpPreference -ExclusionProcess ${NODEPATH}
powershell Add-MpPreference -ExclusionPath ${YARNCACHE}
powershell Add-MpPreference -ExclusionPath ${PROJECTDIR}
powershell Add-MpPreference -ExclusionPath ${TEMPDIR}

echo "DisableArchiveScanning..."
powershell Start-Process -PassThru -Wait PowerShell -ArgumentList "'-Command Set-MpPreference -DisableArchiveScanning \$true'"

echo "DisableBehaviorMonitoring..."
powershell Start-Process -PassThru -Wait PowerShell -ArgumentList "'-Command Set-MpPreference -DisableBehaviorMonitoring \$true'"

echo "DisableRealtimeMonitoring..."
powershell Start-Process -PassThru -Wait PowerShell -ArgumentList "'-Command Set-MpPreference -DisableRealtimeMonitoring \$true'"

Is there any update on the Windows secrets issue? It’s a huge blocker and I can’t find any real mention of it since October :frowning:


I think it would be worth adding the issue where casher fails to restore absolutely specified cache directories to this list, due to a missing -P flag for tar. This issue was identified by @Lekensteyn in It would have saved me a fair bit of time if I had known about this issue in advance.

Thanks for your great work in making Windows available on Travis!

1 Like

Still no news on Windows secrets support?

I ran into the same issue and this makes Windows basically unusable. To collect artifacts from a job we need to sync them (e.g. via S3) but for that we need secrets :slight_smile:

1 Like

Is the fix for the Windows secret still “work in progress”, or at least planned in some future? Or is it a fundamental issue that will never be solved?


Hi, everyone. We have deployed

to disable filtering on Windows. This allows the Windows jobs to continue.

Thank you.

1 Like

@BanzaiMan: yes, that was suggested above. Unfortunately in my case I want to keep the secrets secret :sweat_smile:.


Secret environment variables are not obfuscated on Windows

Was this enabled by default? This seems rather risky, to risk leaking peoples secrets without them explicitly opting in and knowing about it :scream_cat:

Also, is this a temporary limitation, or will it always be this way?

1 Like