path: root/.travis.yml
Commit message (Collapse)AuthorAgeFilesLines
* mac: drop build support for swift versions earlier than version 4.1der richter12 days1-13/+7
| | | | | | | | | | | | this drops support for swift <4.1 and with this support for xcode <=9.2. this was the last setup that is officially working on macOS 10.12. our old legacy build macOS 10.12 + xcode 9.2 is replaced by macOS 10.13 + xcode 9.4.1 with swift 4.1. the macOS 10.13 + xcode 10.1 VM is replaced by the latest macOS 10.14 + xcode 11.3.1 VM. this is the oldest version officially supported by Apple. this is in preparations for the following commit.
* travis: use newer 10.15 VM with newer xcodeder richter2020-11-291-1/+1
* travis: fix macOS 10.13 buildder richter2020-11-291-3/+8
| | | | | | homebrew is removing 10.13 support and some of the dependencies start building rom source now. we will just pin the last working homebrew version, similar to the 10.12 build
* build: fix macOS arm buildsder richter2020-11-221-0/+4
| | | | | | | | | | | remove the hardcoded swift target version and move the version restriction to configure. this was a bad idea anyway and could lead to mismatched object files between obj-c and swift. fix travis 10.12 legacy build. also update the SDK version parser to handle the new macOS 11 scheme. Fixes #8281
* ci/travis: stop installing mingw-w64 packages manuallyJan Ekström2020-10-161-4/+0
| | | | | | As we are now on 20.04, these packages are now available in the repositories. Additionally, they don't need to be separately pulled in, as gcc-mingw-w64 already does that.
* ci/travis: move to a yaml list for required packages for mingw-w64Jan Ekström2020-10-161-2/+8
* ci/travis: bump Ubuntu distro version to focal (20.04)Jan Ekström2020-10-161-1/+1
* travis: fix macOS 10.12 legacy buildder richter2020-09-221-0/+3
| | | | | | | | brew update tries to update the java cask, which it tries to build from source. this takes too long and leads to a timeout of the job. we can't manually remove the java cask because of a bug in the too old brew cask version and the old formula. we just remove the whole cask tap and call it a day, since we don't need it anyway.
* travis: update macOS image from 10.14 to 10.15der richter2020-07-311-1/+1
* travis: make macOS builds fasterder richter2020-07-311-28/+18
| | | | | | | | | | | | | | the problem here is that with time, and because the macOS VMs don't get updated, the homebrew update is getting longer since more and more changes have to be pulled. to prevent that, we cache the homebrew installation folder after the update. that way we don't have to update several months worth of updates every build. for the legacy build we have to check put master again to actually cache the newest homebrew version. additionally to that, we also do the same as on the legacy build, with the addition of not removing all installed formulas but only the ones we don't need. so we don't need to reinstall those.
* travis: fix macOS 10.12 legacy buildder richter2020-07-311-0/+1
| | | | | | | | | just remove all pre installed formulas, since we don't need the majority of it. after that install what we need. this also fixes the brew update of those formulas where the source links were broken like popt. this also helps when the build times out due to building some formulas from source that are not dependencies we need.
* ci: add d3d11 to mingw buildsfan52020-07-011-6/+10
* ci: replace mingw build scriptssfan52020-06-221-6/+24
* CI: add FreeBSD jobJan Beich2020-05-251-0/+37
* travis: reactivate notifications on failureder richter2020-03-251-1/+1
* travis: fix config validation warningsder richter2020-03-251-3/+1
| | | | | private keys should be prefixed with an underscore (_). the sudo key is deprecated and doesn't influence anything anymore.
* travis: shut the fuck upwm42020-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Travis is currently having "problems" and is spamming IRC all the time with pointless failure notifications. Make it so that it hopefully sends a message only when it goes from success to failure, which should exclude these cases. While I'm at it, I'd like to complain how idiotic it is to store CI configuration in a project's source repository. Such a repository should only contain things that are inherently part of the code's function, not part of the organization. You don't store bug reports, build results, the website, developer access controls, etc. in this repository either. But for CI it's supposed to be OK? I'm all for this "configuration as code" thing, but what it should mean is that you store configuration files in some git managed repository, NOT necessarily that you dump them into the main source code repo. There are many arguments why it should not be there, such as this very commit. I have a feeling this is mostly just because all these idiotic web services just want to advertise their shit and bind customers by not giving easy ways to treat source code and CI service configuration orthogonal. And so, the source code repo gets clobbered with stupid shit (both in the set of files and the commit history). It's fairly idiotic and my tolerance for it is waning. (Oh, of course you could probably jump through hoops to make it a separate repo, but I bet that is complicated and has all kinds of downsides because it won't be the way "it's meant to be used".)
* travis: don't send notifications for forksder richter2020-01-261-0/+1
* travis: update macOS images and make building fasterder richter2020-01-091-23/+51
| | | | | | | | | | | | don't build our own ffmpeg anymore and instead use the bottled version from homebrew. update the newest macOS image. also handle macOS 10.12 as a legacy OS since homebrew and Apple stopped supporting it. nevertheless it's helpful to build on that version since it's the last version we support building on. it's a bit special since we have to pin the homebrew-core version to a previous one where all the bottles for macOS 10.12 are still available, otherwise it would build nearly everything from source and that would take ages. also start caching the homebrew cache folder for downloads.
* travis: fix python3 for macOS machinesder richter2019-12-281-1/+6
| | | | | python3 couldn't be set up as system default because it was blocked by the old python2.
* travis: use macOS 10.14 image with xcode 11 instead of xcode 10.2der richter2019-09-221-1/+1
* travis: rework scripts to re-enable macOSJan Ekström2019-09-021-10/+42
| | | | | | | | | | | | | * Adds a script to clone and build FFmpeg as well as to configure and build mpv itself. Currently only used for macOS and contain hard-coded macOS specific options. * Still works with the Linux containers. * Moves our language back to "c" from "generic" * Defines our Linux distribution as "bionic" to get the latest Ubuntu base distribution to be the runner for our containers. * Adds the homebrew add-on for macOS package installation for dependencies. Installs everything required but FFmpeg, as we want to have our own FFmpeg snapshots.
* ci: Remove snapshot-deps config from tw buildsMartin Herkt2019-06-141-2/+0
| | | | | OBS isn’t really set up to support this. If needed, we should instead git clone FFmpeg as part of the CI. I don’t think it is, though.
* travis: enable CI for release branchesJan Ekström2018-09-291-0/+1
* ci: do bootstrap outside the docker containerJan Ekström2018-07-291-0/+1
| | | | | | | This way the docker container in itself does no networking. It seems like travis disabled network access from the actual docker containers.
* ci: add mingw64 targetsMartin Herkt2018-07-051-1/+3
* ci: switch to docker registryMartin Herkt2018-07-051-4/+4
| | | | Much faster build cycles and more consistent download bandwidth.
* ci: switch Travis env language to genericMartin Herkt2018-06-251-1/+1
| | | | This way it doesn’t override CC.
* ci: add more build targetsMartin Herkt2018-06-251-2/+5
| | | | | Travis now builds with Clang and containers with git snapshots of some dependencies.
* ci: Use custom container for Travis buildsMartin Herkt2018-06-251-22/+10
| | | | | | | | Temporary solution. For now, this builds using a container image based on openSUSE Tumbleweed with the current FFmpeg release. More containers will be added (at least with git snapshots of FFmpeg and libass), and Travis will eventually be replaced with something we have more control over.
* Fix recent FFmpeg deprecationswm42018-02-131-0/+1
| | | | | | | | | This includes codec/muxer/demuxer iteration (different iteration function, registration functions deprecated), and the renaming of AVFormatContext.filename to url (plus making it a malloced string). Libav doesn't have the new API yet, so it will break. I hope they will add the new APIs too.
* travis: stop excluding ffmpeg-gitRicardo Constantino2017-12-221-2/+0
| | | | Signed-off-by: Stefano Pigozzi <>
* Restore Libav supportwm42017-12-211-0/+1
| | | | | | | | | | | Libav has been broken due to the hwdec changes. This was always a temporary situation (depended on pending patches to be merged), although it took a bit longer. This also restores the travis config. One code change is needed in vd_lavc.c, because it checks the AV_PIX_FMT for videotoolbox (as opposed to the mpv format identifier), which is not available in Libav. Add an ifdef; the affected code is for a deprecated option anyway.
* travis: remove Libav check for nowwm42017-12-021-1/+0
| | | | | I sure hope they merge the patches for the required hwdec info API, which is already in FFmpeg.
* travis: correctly remove ffmpeg-stable from build matrixwm42017-10-271-1/+0
* travis: adjust ffmpeg URLwm42017-10-271-1/+1
| | | | No idea if this is correct.
* travis: print config.log on failure like appveyorRicardo Constantino2017-08-071-0/+1
* travis: drop libav-stable supportwm42017-08-031-3/+0
| | | | | | | | | | | For libav-stable, we download the Libav tarball, which is failing, because their certificate is broken: ERROR: cannot verify's certificate, issued by `/C=US/O=Let\'s Encrypt/CN=Let\'s Encrypt Authority X3': Issued certificate has expired. I don't intend to support Libav's overly old releases anymore anyway, so if you want to use Libav, use its git master.
* travis: disable OSXwm42017-02-181-1/+1
| | | | | | | Travis being a POS again. Why does the travis config even have tol be part of the source code repo? This makes no sense.
* travis: rebuild website for updated docs on pushStefano Pigozzi2016-09-041-0/+3
* travis: move travis-deps script to TOOLSwm42016-05-121-1/+1
| | | | Don't let it clutter the top level directory.
* manpage: update mpv IRC channelsNiklas Haas2015-04-271-1/+1
| | | | | Moved to #mpv and #mpv-devel, respectively. Travis details were also updated.
* travis: re-enable OSXwm42015-04-071-1/+1
| | | | Let's see if it works better now.
* travis: disable on OSXwm42015-01-031-1/+1
| | | | Useless crap that keeps spamming IRC with timeout "errors".
* travis: restrict build matrix furtherwm42014-11-241-0/+4
| | | | | | | | | | | | | | | | We don't actually want to test all possible combinations; we just want to make sure that each thing (e.g. linux/osx, ffmpeg/libav) is tested once. Exclude Linux + ffmpeg-stable, because ffmpeg-stable is already tested on OSX. Exclude clang on Linux, because OSX needs clang, but Coverity (running on Linux) needs gcc - so we use gcc only on Linux. I also wanted to reduce the matrix to a single configuration when running Coverity, but apparently this is not possible. (See travis-ci/travis-ci#1975.)
* travis: add gcc to the build matrixwm42014-11-241-0/+4
| | | | | | | | For the purpose of running Coverity correctly. Although I'm not sure how well this works. gcc won't work on OSX, and also I'm not sure if Coverity will act up if the build matrix has more than 1 configuration (will it submit multiple scans?).
* travis: another attempt (2)wm42014-11-211-5/+6
| | | | They said YAML is "simple"...
* travis: another attemptwm42014-11-211-4/+2
| | | | I guess it didn't like the duplicate env section.
* travis: attempt to add Coverity integrationwm42014-11-211-0/+15
| | | | | Not sure if this will work. Probably not, because it seems Coverity will be missing some required dependencies.
* travis: add OS X continous integrationStefano Pigozzi2014-07-211-5/+15
| | | | | | | | The travis guys were so nice to activate multi OS support for us (it's a beta feature). So now we build on OS X ass well to check for OS X specific breakage. Later I might investigate further and build with the minimum supported SDK version so that we don't break older systems by using newer Cocoa features.
* travis-ci: update Libav releasewm42014-03-241-0/+1
| | | | | | | | Libav 10 was released, so we can enable testing the stable Libav version again. FFmpeg 2.2 was also released, but since we still support 2.1.4, we stick with the older version. This is better for testing.
* build: drop support for Libav 9wm42014-03-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I have no tolerance for this garbage anymore. There are tons of issues with it (see e.g. previous commit), and there is no reason to use it either. Use Libav git, or Libav 10 when it's released. This also drops support for earlier FFmpeg release, which have exactly the same issues as Libav 9. FFmpeg 2.1.4 is still supported, because it's the latest release, and is reasonably recent. (Although this will probably also be dropped as soon as FFmpeg 2.2 is released.) Assumed version table (lots of nonsensical numbers): FFmpeg 2.1.4 FFmpeg (n2.2-rc2) Libav (v10_beta2) lavu 52.48.101 52.66.100 53.3.0 lavc 55.39.101 55.52.102 55.34.1 lavf 55.19.104 55.33.100 55.12.0 lsws 2.5.101 2.5.101 2.1.2 lavi 3.90.100 4.2.100 4.2.0 lswr 0.17.104 0.18.100 - lavr 1.1.0 1.2.0 1.1.0 libpostproc and libavdevice are not interesting. Following this commit, code needed just to support old Libav versions will start to be removed.
* travis: disable e-mail notificationsStefano Pigozzi2013-11-231-0/+1
* switch the build system to wafStefano Pigozzi2013-11-211-1/+4
| | | | | | | | | | | | | | | | | | | | | | | This commit adds a new build system based on waf. configure and Makefile are deprecated effective immediately and someday in the future they will be removed (they are still available by running ./old-configure). You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`. TL;DR: we couldn't get the same level of abstraction and customization with other build systems we tried (CMake and autotools). For guidance on how to build the software now, take a look at and the cross compilation guide. CREDITS: This is a squash of ~250 commits. Some of them are not by me, so here is the deserved attribution: - @wm4 contributed some Windows fixes, renamed configure to old-configure and contributed to the bootstrap script. Also, GNU/Linux testing. - @lachs0r contributed some Windows fixes and the bootstrap script. - @Nikoli contributed a lot of testing and discovered many bugs. - @CrimsonVoid contributed changes to the bootstrap script.
* travis: remove e-mail notificationsStefano Pigozzi2013-11-081-4/+0
| | | | | Lately Travis sends out many notifications that are false positives caused by timeout. We are annoyed.
* travis: run travis on 'ci' branchStefano Pigozzi2013-06-031-0/+1
| | | | | | | We will use the 'ci' branch to do test builds of big features before they are merged into master. [ci skip]
* travis: fix typoStefano Pigozzi2013-05-201-1/+1
| | | | [ci skip]
* travis: DRY up the yaml fileStefano Pigozzi2013-05-201-6/+6
| | | | | Use YAML's anchor/reference syntax to DRY up the YAML file. Also fix a bug that caused the IRC notification to always take place (even on success).
* add Travis-CI integrationStefano Pigozzi2013-05-191-0/+29
Travis-CI [1] is a continous integration cloud service. It is free for open-source projects and tigthly integrated tiwh GitHub so there is really no reason for us not use it. :) For now we are going to do a total of 4 builds, mainly to test ffmpeg/libav API breakage: * ffmpeg-stable, libass-stable * ffmpeg-git, libass-stable * libav-stable, libass-stable * libav-git, libass-stable The compiler that is currently used is clang for two reasons: * running 8 build targets would be quite wasteful and take a long time * clang is less tested and used during development than gcc (especially on linux) Currently Travis doesn't support OS X environments alongside Linux ones [2]. When it will, we will add a fifth build target to test OS X compilation breakage. README was moved to markdown to add the little build status image. I ran some tests with my GitHub fork and couldn't get images to show up using ReStructured Text. [1]: [2]: travis-ci/travis-ci#216