Free continuous integration platform for GitHub projects.

Related tags

travis-ci
Overview

Do not open new issues here!

Travis CI

Travis CI is a hosted continuous integration and deployment system. You can now test and deploy open source and private projects on travis-ci.com! You can read more about this change here.

Move to Forum

We are moving to our new community forum: Travis CI Community! As part of this move, we’ll be able to better follow and reply to threads, along with making it easier for you to find solutions and answers. We’ll be making our best efforts to answer currently existing threads, or directing them to the new community forum.

Link to the Community Forum: https://travis-ci.community

For current outages and incidents such as slow network connections, subscribe to https://www.traviscistatus.com.

Other support issues may be directed to [email protected] where our support team will be glad to assist.

This repository contains the central issue tracker for the Travis CI project.

Documentation

Documentation for the Travis CI project can be found at https://docs.travis-ci.com.

Other repositories

Travis CI consists of many different sub-projects. The main ones are:

travis-api

travis-api is the Sinatra app that's responsible for serving our API. It responds to different HTTP endpoints and runs services in travis-core. Very little logic is in this repository.

travis-build

travis-build creates the build script for each job. It takes the configuration from the .travis.yml file and creates a bash script that is then run in the build environment by travis-worker. This repository also hosts the source for language-specific scripts.

travis-cookbooks

travis-cookbooks holds the Chef cookbooks that are used to provision the build environments.

travis-hub

travis-hub collects events from other apps and notifies other apps about the events. For example, it notifies travis-tasks about builds starting and finishing so notifications can be sent out.

travis-hub is also responsible for enqueueing jobs that have been created and enforcing the Quality of Service restrictions, such as the number of concurrent builds per user.

travis-listener

travis-listener receives notifications from GitHub whenever commits are pushed or pull requests are opened. They are then pushed onto RabbitMQ for other apps to process.

travis-logs

travis-logs receives log updates from travis-worker, saves them to the database and pushes them to the web client. When a job is finished, travis-logs is responsible for pushing the log to Amazon S3 for archiving.

travis-support

travis-support holds shared logic for the different Travis CI apps. It is different from travis-core in that it holds more generic things, like how to run an async job or how to handle exceptions.

travis-tasks

travis-tasks receives notifications from travis-hub and sends out notifications to the different notification providers as needed.

travis-web

travis-web is our main Web client. It is written using Ember and communicates with travis-api to get information and gets live updates from travis-hub and travis-logs through Pusher.

travis-worker

travis-worker is responsible for running the build scripts in a clean environment. It streams the log output to travis-logs and pushes state updates (build starting/finishing) to travis-hub.

Issues
  • Adding BitBucket support

    Adding BitBucket support

    Hello. It will be very good to have BitBucket support added.

    feature-request 
    opened by KOLANICH 219
  • Support Windows and OS X

    Support Windows and OS X

    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
    travis-worker feature-request 
    opened by steveklabnik 208
  • Build status unknown persists

    Build status unknown persists

    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?

    opened by qurben 115
  • make build results pngs less blurry

    make build results pngs less blurry

    nice and clear like the octicons! https://github.com/blog/1106-say-hello-to-octicons

    feature-request 
    opened by borgified 94
  • Xcode 5 / iOS 7 - Simulator fails to launch, or TEST_HOST failed to run

    Xcode 5 / iOS 7 - Simulator fails to launch, or TEST_HOST failed to run

    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

    bug mac objective-c 
    opened by bennyguitar 94
  • fatal: destination path 'xxxx' already exists and is not an empty directory.

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

    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.

    bug travis-build stale 
    opened by PeterDaveHello 78
  • Do you guys still want to try and hide?

    Do you guys still want to try and hide?

    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.

    opened by tjordanchat 78
  • Xcode 8.1 support

    Xcode 8.1 support

    Please add Xcode 8.1 support

    osx_image: xcode8.1

    opened by heyzooi 77
  • Android as first class citizen

    Android as first class citizen

    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

    feature-request android 
    opened by gildegoma 75
  • Add Python 3.7 option

    Add Python 3.7 option

    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
    
    python xenial 
    opened by Harmon758 74
  • Detect temporary download errors and retry later

    Detect temporary download errors and retry later

    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?

    feature-request 
    opened by HariSekhon 3
  • Power and LinuxOne Support

    Power and LinuxOne Support

    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

    feature-request 
    opened by gdams 6
  • Allow --no-single-branch git option (dupe of #4806)

    Allow --no-single-branch git option (dupe of #4806)

    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. 🙏

    feature-request travis-build good first issue 
    opened by drd 2
  • Environment Variables are insecure and transferred to new repository owners

    Environment Variables are insecure and transferred to new repository owners

    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.

    bug github-sync security 
    opened by AWegnerGitHub 17
  • Provide access to the pull request's body

    Provide access to the pull request's body

    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.

    feature-request travis-build 
    opened by nex3 8
  • Pull request title in environment variables

    Pull request title in environment variables

    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.

    feature-request travis-build 
    opened by 3nids 8
  • Add warning to CLI when running encrypt-file on Windows

    Add warning to CLI when running encrypt-file on Windows

    Due to #4746, travis encrypt-file does not work on Windows. But, there's no indication that it doesn't work. It appears to work, but an encrypted file fails to unencrypt when the build is running, which can result in hours of debugging.

    travis encrypt-file works fine on non-Windows machines.

    Could a warning be added to the Travis CLI, when running encrypt-file on Windows, either stating that it is unsupported or is known to not work?

    travis-build cli important 
    opened by tdmalone 6
  • building every revision

    building every revision

    In order to facilitate git bisect, we have a requirement that every commit can be built. It does not have to pass testing, but it has to compile. If it doesn't, then it's a problem. We have a script that builds every revision since the last time we did a version tag, but it's unreasonably long winded, and just now, we ran out of compute time since we pushed a particularly long rebase to github. This seems like something that travis could keep track of if we configured it to pay attention. Maybe there is some way to do this that I've missed, or maybe it's a good feature request.

    feature-request 
    opened by mcr 7
  • [Feature request][Python] Automatically set last stable version

    [Feature request][Python] Automatically set last stable version

    1. Summary

    It would be nice, if would be possible, that Travis CI can automatically set the latest Python stable version, that developers doesn't need to set specific version.

    2. Argumentation

    I develop Python packages. I want, that my packages works on latest stable Python version. Part of my example .travis.yml file:

    language: python
    python:
      - "3.6.4"
    

    When new Python version release, I need to change 3.6.4 to 3.6.5 in each my project, then I should change value to 3.6.6, 3.7.0 and so on. It may take a lot of time.

    3. Expected behavior

    Example part of .travis.yml:

    language: python
    python:
      - "stable"
    

    Travis CI will automatically use the latest stable Python version, what is available on Travis CI.

    It already realized in Travis CI for nightly Python versions:

    language: python
    python:
      - "nightly"
    

    Thanks.

    feature-request python 
    opened by Kristinita 7
  • Continuous deployment to different stages on different time frames.

    Continuous deployment to different stages on different time frames.

    Hi there, I was wondering if you have something like what you describe here but with the option to manage the time in which we would like this to happen? for example we would like to deploy to develop at 08:00am, to staging at 13:00pm and to production at 21:00pm (just to give an example) so in the middle we will be able to take a look around the different stages and see if everything is working smoothly :+1: . Do you have this type of functionality available?

    feature-request scheduler 
    opened by nisevi 1
A static site for the Jenkins automation server

jenkins.io This repository is what powers the Jenkins website. This uses Awestruct with Asciidoctor under the hood to provide a very useful and compel

Jenkins Infra 172 Sep 18, 2021
JGit An implementation of the Git version control system in pure Java.

JGit can be imported straight into Eclipse and built and tested from there. It can be built from the command line using Maven or Bazel. The CI builds use Maven and run on Jenkins.

Eclipse Foundation 1k Jul 5, 2021