Android项目持续集成实践之Gitlab CI(Docker版本)

接上一篇 Android项目持续集成实践之Gitlab CI.

在我看来,.gitlab-ci.yml 配置还是有些复杂,写的脚本还是有点多,有没有办法更精简一点呢?

有,那就是Android环境Docker化。(注:对Docker感兴趣的同学,请参考这本书《Docker —— 从入门到实践》)。

我在这本书的指导下封装了一个包含Android开发环境的Docker镜像。
1. https://github.com/snowdream/docker-android
1. https://hub.docker.com/r/snowdream/docker-android/

现在有了合适的Docker镜像,.gitlab-ci.yml 将会变得非常简单:

image: snowdream/docker-android:1.0

build:
  script:
    - gradle assembleRelease
  artifacts:
    paths:
    - app/build/outputs/

第一行的意思是,采用标签为1.0,名称为snowdream/docker-android的Docker镜像,用于本工程的CI环境。

是不是很简单呢?

详细的构建过程日志太长,我就不贴了。链接如下:
https://gitlab.com/snowdream/Citest/builds/2155883

如果你在使用过程中,碰到什么问题,可以通过以下方式联系我:

  • Email:yanghui1986527#gmail.com
  • QQ Group: 529327615
时间: 2024-11-03 17:36:17

Android项目持续集成实践之Gitlab CI(Docker版本)的相关文章

Android项目持续集成实践之Gitlab CI

简介 持续集成(Continuous integration)是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误. 入门 下面我们来简单介绍,如果通过Gitlab CI来对Android项目持续集成. 一言不合,先甩给你一个项目链接:https://gitlab.com/snowdream/Citest 项目很简单,就是一个默认创建的Andro

Jenkins与Docker的持续集成实践

本文讲的是Jenkins与Docker的持续集成实践[编者的话]持续集成(CI/CD)是一种软件开发实践.用于帮助团队成员频繁.快速的集成,测试他们的工作成果,以尽快发现集成错误. 更频繁.更早的集成意味着更早的发现问题.通过持续集成,及时发现和解决代码故障,提高代码质量,减少故障处理成本等等. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的

【狂云歌之unity_vr】unity项目持续集成dailybuild以及多平台打包管理

[狂云歌之unity_vr]unity项目持续集成dailybuild以及多平台打包管理 前言  持续集成的意义就不多说了.unity通常打包一般就直接build&run,但是在实际项目中,往往直接在服务器build包,所以命令行打包必不可少,这里一方面分享unity打包做持续集成,一方面分享使用unity管理多平台打包,例如一个vrapp需要支持gear版本,支持小米版本,支持cardboard版本等等~懂的人就知道这里具有一定的管理维护成本.  我们做vr相关的app,需要支持gear.ca

Xamarin.Android VSTS 持续集成

这些天做了一个基于 VSTS 的 Xamarin.Android的持续集成,这里分享下 Build Agent 环境需求 DotNetFramework         msbuild         visualstudio         AndroidSDK         JDK Xamarin.Android Build的部分分为以下步骤: 1. 还原NuGet包 a. 这步之所以存在,原因为我使用了Xamarin.Android进行编译,而没有直接对解决方案使用MSBUILD进行编译

IOS6.1单元测试持续集成实践

最近项目测试需要,调研并实践了下IOS下单元测试工具和框架.目前比较流行的工具有xcode自带的OCUnit.GHUnit等,我选择的是GHUnit,因为相比OCUnit,GHUnit具有如下优势: 1.开源框架 2.支持重复测试.单一测试.集成测试. 3.断言方法丰富 4.支持持续集成 5.测试类型多样(UI和Command Line) 官方地址如下:http://gabriel.github.io/gh-unit/ GitHub下载地址:https://github.com/gabriel/

云计算基础设施持续集成实践

[演讲PDF]: https://yq.aliyun.com/attachment/download/?id=1837 [演讲视频]: https://yq.aliyun.com/edu/lesson/551 研发和传统基础设施交互方式 通常情况下,在开发过程中需要和基础设施打交道,需要在项目中申请开发.测试以及预发生产环境.在IDC时代,我们需要向IT部门申请这些资源,其批准后,我们才能获得这些资源.如果这些资源恰巧不足,我们只能等待购买新的资源或者更换其他资源. 当拿到这些资源之后,需要对开

Jenkins 持续集成实践(以网易蜂巢为例)-1 Master 节点的创建

使用场景 当 Github 发生 push 操作时,能够触发测试环境的持续集成. 步骤 搭建 master 节点 蜂巢在官方 jenkins 镜像的基础上 预先安装了 jenkins 的插件 预置了用户 (jenkins/jenkins) jenkins节点分为 master 节点 slave 节点 Master/Slave 相当于 Server/Agent 的概念 Master 节点提供 web 接口来让用户管理 job 和 slave job 可以运行在 master 本机也可以被分配到 s

持续集成实践小结[1] —UI自动化

背景介绍 按照组织上的安排,咱游击到了S产品(一个快速成长中的Web产品)开搞持续集成. 考虑到S产品核心业务单一明确,前端功能简单,业务逻辑主要在后端的特点,制定了持续集成的实施策略: UI自动化为辅,用例少一点,精一点,降低维护成本,用例设计以冒烟和页面跳转,走通业务流程为主,目的是保障一个高可测性的测试环境: 单元测试重点跟进,自顶向下逐步覆盖各层接口,多覆盖各种分支路径,与UI自动化形成互补. 这里有个小插曲,我和S产品的测试负责人关于UI自动化用例的粒度和覆盖度有一些歧义,测试负责人坚

Android热更新开源项目Tinker集成实践总结

前言 最近项目集成了Tinker,开始认为集成会比较简单,但是在实际操作的过程中还是遇到了一些问题,本文就会介绍在集成过程大家基本会遇到的主要问题. 考虑一:后台的选取 目前后台功能可以通过三种方式实现: 1.自己搭建后台布丁下发系统 2.第三方提供的服务,目前如原微信simsun大神的个人tinkerpatch平台,目前出于内测阶段,暂时免费.后期应该会按下发量对app进行收费. 3.腾讯Bugly提供的服务,提供了热更新的下发后台,集成到了bugly的升级sdk中.免费. 根据公司的精神,我