1

我正在使用 travis CI 构建WebRTC库。

这运行良好，但需要大量时间，并且构建越来越经常以消息结束：

该作业超过了作业的最大时间限制，并且已被终止。

可以查阅travis 日志失败的日志

期间gclient sync：

_______ running 'download_from_google_storage --directory --recursive --num_threads=10 --no_auth --quiet --bucket chromium-webrtc-resources src/resources' in '/home/travis/build/mpromonet/webrtc-streamer/webrtc'
...
Hook 'download_from_google_storage --directory --recursive --num_threads=10 --no_auth --quiet --bucket chromium-webrtc-resources src/resources' took 1255.11 secs

我禁用了测试，所以我认为这没用而且需要很多时间。

无论如何要给出一些论点或设置一些变量来避免这个时间昂贵的任务吗？

4

2 回答 2

2

一种不下载chromium-webrtc-resources依赖项 DEPS中定义的方法

{
    # Download test resources, i.e. video and audio files from Google Storage.
    'pattern': '.',
    'action': ['download_from_google_storage',
               '--directory',
               '--recursive',
               '--num_threads=10',
               '--no_auth',
               '--quiet',
               '--bucket', 'chromium-webrtc-resources',
               'src/resources'],
  },

是修补它删除此部分或添加错误的条件。

为了打补丁，我使用了以下命令：

sed -i -e "s|'src/resources'],|'src/resources'],'condition':'rtc_include_tests==true',|" src/DEPS

这节省了大约 2000 万，并允许 travis 构建保持在超时以下。

于 2017-10-18T19:10:11.563 回答
1

您可以将整个工具链烘焙到 docker 映像中，并在其中运行您的实际测试/构建。将 docker 镜像更新委托给另一个自动化进程（例如 travis-ci cronjob）。

另一个好处是您现在可以完全控制工具链的某些部分何时更改。我觉得这很重要。

编辑：一些要阅读的资源。

于 2017-10-16T07:55:59.167 回答