This will have to be done in steps, so I might break this issue down as support gets closer. Eventually, I'd like to make it such that the yaml file has something like:

os:
  :windowsxp
  :osx
  :linux

Or whatever. So you can build on multiple operating systems as well as just Linux.

This has some interesting issues:

1. licensing
2. availablility
3. combinatorial explosion of rubies and platforms

The badge for https://travis-ci.org/Vennik/contextproject has been 'Build status: Unknown' for more than a day, while we currently have had multiple passing builds in that repository.

Is there a way we can fix this?

failed: The simulator failed to start, or the TEST_HOST application failed to run.

Almost makes it through to begin testing, when this message kills it. This is running with xctool instead of xcodebuild

I got this problem for a while, not 100% probability to occure, maybe 50%, is possible to fix it?

Thanks!!

https://travis-ci.org/cdnjs/cdnjs/builds/33241830

Using worker: worker-linux-12-1.bb.travis-ci.org:travis-linux-7 $ git clone --depth=1 --branch=master git://github.com/cdnjs/cdnjs.git cdnjs/cdnjs Cloning into 'cdnjs/cdnjs'... remote: Counting objects: 141433, done. remote: Compressing objects: 100% (96977/96977), done. remote: Total 141433 (delta 41382), reused 137759 (delta 41054) Receiving objects: 100% (141433/141433), 304.73 MiB | 21.66 MiB/s, done. Resolving deltas: 100% (41382/41382), done. Checking connectivity... done. /home/travis/build.sh: line 175: 1307 Killed git clone --depth=1 --branch=master git://github.com/cdnjs/cdnjs.git cdnjs/cdnjs

The command "eval git clone --depth=1 --branch=master git://github.com/cdnjs/cdnjs.git cdnjs/cdnjs" failed. Retrying, 2 of 3.

fatal: destination path 'cdnjs/cdnjs' already exists and is not an empty directory.

The command "eval git clone --depth=1 --branch=master git://github.com/cdnjs/cdnjs.git cdnjs/cdnjs" failed. Retrying, 3 of 3.

fatal: destination path 'cdnjs/cdnjs' already exists and is not an empty directory.

The command "eval git clone --depth=1 --branch=master git://github.com/cdnjs/cdnjs.git cdnjs/cdnjs" failed 3 times.

The command "git clone --depth=1 --branch=master git://github.com/cdnjs/cdnjs.git cdnjs/cdnjs" failed and exited with 128 during .

Your build has been stopped.

I ahve opened an issue over travis-ci.org using Microsoft development tools illegally. They are continuing their effort to gain developer acceptance by offering these developers free access to Microsoft development tools free of charge. I ask that the US FBI investigate travis-ci.org as they are skirting US laws and ask that they pay fair taxes for their actions.

Below is my issue which travis-ci.org closed to hide this matter.

I am so glad that you responded. It seems to me that travis-ci.org is trying to set up a file sharing site but instead of sharing movies their "great" idea is to share Microsoft development tools and allow developers to use these tools without purchasing the tools. To me this is no different than a movie sharing site. I believe that the FBI should be looking into travis-ci.org because they are looking to defraud Microsoft out of a lot of money. travis-ci.org is planning to place Microsoft development tools online, free of charge, without giving Microsoft any money. These guys have run amok of American laws and are probably a criminal organization. We need to stop organizations like travis-ci.org from evading US laws and make those responsible for this violation responsible for their acts. travis-ci.org is an asthma to the USA and should be shut down before they infringe on and take money from our beloved Microsoft.

In continuation to travis-ci/travis-worker#56 discussion, I open this issue to specify the features of upcoming android builder on Travis CI. Here is a first draft that I want to review and get accepted (ideally by core team and community) before we (presumably @andrewhr and me) code the last missing piece of the puzzle (a.k.a the travis-build part...).

Dear Android Developers, I'm looking forward to receiving your comments and corrections, so that we design it at best! I'm in favor to keep it simple (if possible!), and maybe following proposal should be simplified already (you'll better know since I'm not - yet - Android developer)... I wish that we can get it soon online!

Android-specific Features in .travis.yml

• Emulator creation and auto-startup (optional, but enabled by default)
  • Note: the wait_for_android_emulator script will certainly be preinstalled as part of Android SDK, via travis-cookbooks setup phase.
• Update SDK Components (optional, not sure if it should be enabled by default...?)
• Auto-export typical android environment variables and mangae related build matrix

So, an android .travis.yml could look like following:

language: android
jdk:      openjdk7
script:   mvn install -Pintegration-tests -Dandroid.device=test
android:
  - { target: android-8,  sdks: [android-8],             abi: armeabi}
  - { target: android-10, sdks: [android-10],            abi: armeabi}
  - { target: android-16, sdks: [sysimg-16],             abi: armeabi-v7a}
  - { target: android-17, sdks: [android-17, sysimg-17], abi: armeabi-v7a}

android_toolkit:   # below would be default values...
  start_emulator: true
  update_sdk:     'platform-tools,build-tools-18.0.1,extra-android-support,$ANDROID_TARGET,$ANDROID_SDKS'

This way, ANDROID_TARGET, ANDROID_SDKS and ANDROID_ABI environment variables would be automatically exported.

• if android_toolkit.update_sdk, default before_install will echo y | android update sdk --filter ${travis_android_sdk_update_filter} --no-ui --force > /dev/null
• if android_toolkit.start_emulator, default before_script will:
  • echo no | android create avd --force -n test -t $ANDROID_TARGET --abi $ANDROID_ABI
  • emulator -avd test -no-skin -no-audio -no-window &
  • execution of kind of wait_for_android_emulator script, most probably inspired from embarkmobile/android-maven-example

I know that having android.target, android.sdks and android.abi YAML-subelements is not quite standard in current Travis CI style (usually language attributes - php, ruby, ... - are just flat lists of versions), but so far I found it better than having something like:

android:
  - android-8
...
  - android-17
android_sdks:
  - android-8
...
android_abi:
  - armeabi
  - armeabi-v7a

that would lead to matrix explosion (and certainly many cases to systematically exclude). The idea is to get something as simple as what people currently do with the generic env.matrix, but I'm open to any other way to express it.

(My) Open Questions:

• @joshk do you agree with android YAML subelements syntax?
• what would be the defaults for android target, sdks and abi? (for a single-row build matrix).
• what would be the standard build script command to run for Gradle-based projects? gradle connectedInstrumentTest ?
• what would be the standard build script command to run for Maven-based projects? mvn install -Pintegration-tests -Dandroid.device=test ?
• what would be the standard build script command to run for Ant-based projects? ant test ?
• Should emulator name (typically "test") or options (e.g. -no-skin) be configurable ?
• Should emulator creation, startup and wait_for commands be more configurable (e.g. override startup command, sleep time, max retry) ? Having already ANDROID_ vars and wait_for_android_emulator, it will be easy to override default before_install or before_script sequences
• Is it common/realistic to start more than one emulator in the same test run?

Related Issues:

• #445 (original feature request). Here, I preferred to open a fresh new issue focused on the requirement definition of the travis-build android builder.
• travis-ci/travis-worker#56 (linux 32bit/64bit compatibility issue)
• travis-ci/travis-cookbooks#153 (for the android-sdk preinstallation on the build VM)

Examples of Android Projects:

This proposal has been inspired from these examples:

• Gradle: https://github.com/pestrada/android-tdd-playground/blob/master/.travis.yml
• Maven: https://github.com/embarkmobile/android-maven-example/blob/master/.travis.yml
• Ant: https://github.com/mixi-inc/Android-Device-Compatibility/blob/master/.travis.yml
• Other Ant: https://github.com/leandog/brazenhead/blob/master/build.xml

/cc @joshk @andrewhr @rkistner

Now that Python 3.7.0 has been released.

The current workaround seems to be adding it to the build matrix.include configuration using xenial in .travis.yml:

# Existing Python versions
python:
  - 2.7
  - 3.4
  - 3.5
  - 3.6
# Enable 3.7 without globally enabling sudo and dist: xenial for other build jobs
matrix:
  include:
    - python: 3.7
      dist: xenial
      sudo: true

or alternatively:

matrix:
  include:
    - python: 2.7
    - python: 3.4
    - python: 3.5
    - python: 3.6
    - python: 3.7
      dist: xenial
      sudo: true

Hello,

PostgreSQL 10.0 has been released today: https://www.postgresql.org/about/news/1786/. Can we please have it added to the build environment? 🎉

Thanks.

We have been seeing significant inconsistencies in travis since Saturday 1/20/2018. some builds error with timeouts while when restarting the same build they finish in ~6 minutes.

look at the screen shot of this log:

this is getting to the point where it is slowing down development as it is creating a queue of PRs that are constantly failing and when restarted may or may not pass but every once in a while they do.

Please advise.

Thanks

For our build environment we want to start using PhantomJS 2.0 to address stability problems we are encountering with PhantomJS 1.9.7 randomly crashing. Currently only phantomjs 1.9.7 is available in the build environment. Building phantomjs manually as part of our build is not feasible as it requires us running apt-get for the necessarily dependencies, and the build takes multiple hours to run in order to compile phantom JS.

It would be great if the PhantomJS 2.0 binary was available in the build environment. I think it would make sense to have multiple ver of phantomjs available, where we could set a property in our .travis.yml to select the version we want to use.

thanks!

Problem initially reported in https://groups.google.com/forum/m/?fromgroups#!topic/travis-ci/YG9j5wN4YeE

See attempts to install chrome browser and test driver on the fly here: https://travis-ci.org/freedomsponsors/www.freedomsponsors.org/builds

As pointed out below, this a well-known integration problem: Chrome cannot be executed in a OpenVZ container/guest, because of suid binaries. Details there:

• http://code.google.com/p/chromium/issues/detail?id=31077 (old/historical bug report)
• https://code.google.com/p/chromium/issues/detail?id=138505 (more recent bug report for ubuntu 12.04)

//cc @tonylampada

One issue I find a lot is that upstream repositories of dependencies are sometimes temporarily unavailable.

This breaks builds and makes your project look unstable when in fact a simply retry a short while later would have solved it.

I expect a few regex of the most common download failed error messages from pip, wget, curl, apt, maven, sbt, gradle etc would fix 95% of these occurrences by just rescheduling the build to try again after a short while. If a handful of retries later over the next few hours don't resolve it then fine leave it marked as failed.

Right now having to go to Travis to investigate these build failures and manually click retry to get it to pass is not something humans should really have to be dealing with, these are the sorts of things programming is invented to automate.

Currently this leaves public projects in Error or Failed state until somebody notices and goes and investigates, then click retry. I use daily cron jobs too which might succeed the next time (or they may fail again with a temporary download error or "server too busy, try again later" from an apache mirror or something), but even if the next daily cron worked, do you really want to leave you public projects with visibly broken CI builds for a day that makes the project look unstable?

Hi all,

How much work would it be to add Power/LinuxOne support to Travis? I might be able to provide hardware if I can be put in touch with the right person?

Regards

Overview

It is useful to be able to compare across branches for certain CI-related tasks. With current versions of git, cloning using the --depth flag also automatically enables the --single-branch option, causing git to fetch only the specified branch for the commit travis is building. As pointed out in #4806, there are ways around this, but they have a significant performance penalty: running git fetch --unshallow retrieves the entire commit history, which for many projects, is an undue burden.

Request

Please allow an option to specify --no-single-branch in the travis config. 🙏

If a GitHub repository is transferred to a new owner, all associated environment variables are transferred as well - including the "secure" ones.

Reproduction - Short Version

The short version is this:

1. On one GitHub account, create a repository with a .travis.yml file
2. On the Travis CI account associated with step 1, set up an environment variable and elect not to show the value in the build log
3. Transfer the GitHub repository to another account.

At this point, the environment variables defined in step 2 are accessible by the new owner from step 3.

The longer version is that these "secure" variables aren't actually secure. Simple string manipulations can expose the variables in the build log and they are transferred to the new owner.

I've written a longer write up on this bug here. It was originally reported in December of 2017 to the security team, but multiple followups haven't been responded to. At this point, we're over three months since the initial report and I feel others need to know that their environment variables can be accessed if you transfer your repository or if you have a malicious commit applied to your build scripts, where you manipulate the build log string outputs to show the variable values.

It's useful to be able to send messages to build infrastructure via the pull request message—things like [ci skip], but with semantics specific to the project at hand. It would be really useful if, for pull request builds, Travis provided access to the pull request message as an environment variable, file on disk, or something similar.

It's possible to get this via the GitHub API, and in practice this is what we do in the sass-spec repo. However, this is very flaky; we regularly run into GitHub rate limits which prevent the logic from working correctly. Since Travis already has access to the information about the pull request, it would be great if it could provide that information to the build.

I would like to get the pull request title in the env variables. It is not easily accessible at the moment.

From what I could dig into, in scheduler, the worker request needs to be extended to get the PR title https://github.com/travis-ci/travis-scheduler/blob/master/lib/travis/scheduler/serialize/worker/request.rb and adapt the worker https://github.com/travis-ci/travis-scheduler/blob/master/lib/travis/scheduler/serialize/worker.rb

And in build, the var needs to be added https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/env/builtin.rb

My knowledge to pull a request my self is too low, I could not find (did not know what to look for) the way to get the PR title.