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

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:

1 Like

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

Note that secrets obfuscation has always been best-effort. (The log viewer may be able to obfuscate the values on Linux/OSX, but in general it isn’t possible to prevent Turing-complete rogue code from sending them over the network to a third-party.) While Travis doesn’t make secrets available to external pull requests, it is still up to you to review pull requests for any rogue secret-exposing code before merging them in (after which that code will get to see your secret variables).

So no security risk right now, provided that project members with approval/merging rights are doing their due diligence on external code.

So no security risk right now, provided that project members with approval/merging rights are doing their due diligence on external code.

Today the secrets are obfuscated on Linux and macOS (I’m talking about generally in logs, and not from malicious PRs). If someone sees you support Windows and enables it without reading through all of this forum/thread, they would not know that secret obfuscation has been deliberately disabled.

It seems very easy for someone to turn on Windows support and not realise that secrets they thought were being obfuscated are not. If you can’t support it, IMO it would be better to error the job explaining it’s not supported and let them explicitly opt-in to having it off. It just seems very dangerous to be leaking secrets when a user believes they are being obfuscated.

Any movement on windows debug builds?