关于配置travis-ci持续集成python pytest测试的相关记录

首先由于公司用上了高大上的travis-ci商用版,一直想试着学学弄弄看。现在要写openapi的相关测试,而且要在travis-ci上集成。我就想体验一下这个过程。所以自己弄了一个public的仓库先尝试一下。

首先了解travis-ci的相关比较重要。https://docs.travis-ci.com/user/customizing-the-build/

这里首先介绍了需要集成测试的语言指定方面的问题。travis-ci的所有配置都集中在一个叫做 .travis.yml 的文件下面。这个文件告诉travis-ci

  • What programming language your project uses
  • What commands or scripts you want to be executed before each build (for example, to install or clone your project’s dependencies)
  • What command is used to run your test suite
  • Emails, Campfire and IRC rooms to notify about build failures

所以可以看出,相关的自定义处理都在这个文件里面进行写入。下面我继续翻译一下文档。

创建travis-ci一般由两步构成:

1. 安装:安装依赖和需求

2. 脚本:运行编写的脚本文件

你可以执行自定义命令在安装之前before_install或者在运行脚本之前before_script或者在运行脚本之后after_script.

在before_instll里,你可以安装一些额外的需求比如说ubuntu包和一些自定义的服务。

下面太简单懒得翻了直接贴

You can perform additional steps when your build succeeds or fails using the after_success (such as building documentation, or deploying to a custom server) or after_failure (such as uploading log files) options. In both after_failure and after_success, you can access the build result using the $TRAVIS_TEST_RESULT environment variable.

The complete build lifecycle, including three optional deployment steps and after checking out the git repository and changing to the repository directory, is:

  1. before_install
  2. install
  3. before_script
  4. script
  5. after_success or after_failure
  6. OPTIONAL before_deploy
  7. OPTIONAL deploy
  8. OPTIONAL after_deploy
  9. after_script

如果步需要第一步安装的话 可以直接设置 install: true

时间: 2024-08-07 00:17:29

关于配置travis-ci持续集成python pytest测试的相关记录的相关文章

(二) 关于配置travis-ci持续集成python pytest测试的相关记录

接上篇 上篇只是非常官方的描述了一下travis-ci是包括了些什么部分会如何工作但是并没有深入介绍也没有写demo. 这里先贴上一个我已经测试好了的python_travis-ci的环境 https://github.com/piperck/flask_pytest_demo#flask_pytest_demo 只要clone这个仓库,并且发pr上来就可以发现,ci就会开始集成,测试和集成内容都由配置脚本配置完成,在这个demo里现在.我只是配置了几个最简单的测试脚本,并且把他们都跑通了. 从

GitLab CI持续集成配置方案

目录 1. 持续集成介绍 1.1 概念 1.2 持续集成的好处 2. GitLab持续集成(CI) 2.1 简介 2.2 GitLab简单原理图 2.3 GitLab持续集成所需环境 2.4 需要了解知识 3. 搭建GitLab持续集成环境(NET版) 3.1 环境搭建 3.1.1 基础环境搭建 3.1.2 Git安装 3.1.3 NuGet安装 3.2 相关配置 3.2.1 Git环境变量配置 3.2.2 PowerShell调用测试 3.2.3 GitLab-Runner下载 3.3 Git

记一次完整的CI持续集成配置过程(.net core+Jenkins+Gitea)

Jenkins大家一定很熟悉.以前我也配过,这次的需求是当后台开发工程师向git server提交代码以后,jenkins服务器自动去抓取,然后编译,发布,我起初觉得这是个很简单的事情,应该半个小时搞定吧. 事实上,不但半个小时没搞定,我最后 折腾了三天,经历了38次失败,最终在第39次才完全配置成功. 把经历的过程写下来,供后来者参考,避免踩坑. 一.本次配置环境: 1.需求: 后端工程师提交代码->Push到Git Server(使用Gitea自已搭建)->经路由器映射触发内网Jenkin

简单搭建Gitlab CI持续集成环境

简单搭建Gitlab CI持续集成环境 简单介绍Gitlab CI的功能 从GitLab 8.X 开始,GitLab CI就已经集成在GitLab中,我们只要在项目中添加一个.gitlab-ci.yml文件,然后添加一个Runner,开启Runner,即可进行持续集成.而且随着GitLab的升级,GitLab CI变得越来越强大. GitLab Runner 在没使用过Gitlab之前,我也有一个困惑,到底Gitlab Runner是什么东西.它的作用是什么?</br>GitLab Runne

Artifactory &amp; GitLab CI持续集成实践

GitLab CI支持创建多个构建,并评估每次代码提交是否通过测试和以及对您产品的影响.在构建过程中,会生成大量二进制文件,如果不能正确的大规模管理这些文件,就会导致二进制文件管理混乱.为了克服这个问题,Artifactory被无缝地集成到GitLab CI构建过程中,以便更好的发布和管理这些二进制文件,并通过JFrog CLI, GitLab CI缓存.发布您的依赖包.制品包和构建信息到Artifactory. 这篇文章描述了如何将 GitLab CI 与 Artifactory 集成在一起,

如何用 Gitlab 一键实现 CI 持续集成?

背景 在目前快节奏生活已经成为社会风潮的大背景下,越来越多的互联网公司为了其应用产品能更快的掌控风向脉搏,抢占市场红利,需要更快速的应用产品开发上线,在市场的反馈下,不断的迭代新功能.在此需求下,持续集成,持续部署,持续交付被越来愈多公司所推崇,DevOPS文化的兴起,一方面是实践打破运维与研发的堡垒之墙,另一方面也是敏捷开发过程中的必要产物. 提高软件开发效能,快速迭代.快速试错,以及根据自己开发团队特点,使用怎样的技术手段,才能是软件开发效能最高,更为快速敏捷,以及怎样才能满足产品能在最短周

python unittest 测试所有相关单元测试

python unittest 测试所有相关单元测试 python -m unittest discover project_directory "ut_*.py" 原文地址:https://www.cnblogs.com/bingwork/p/9714318.html

Gitlab CI 持续集成的完整实践

本着公司团队初创,又在空档期想搞点事情,搭建了私有Gitlab的契机,顺便把持续集成搭建起,实现了对Python服务端代码的单元测试.静态代码分析和接口测试的持续集成.总体架构如下: 执行过程: 开发提交代码后,自动触发gitlab-runner拉取executor镜像执行单元测试,单元测试代码中包含上传测试结果到x-utest测试平台: 单元测试通过后,gitlab-runner拉取sonar-scanner镜像执行静态代码分析,分析结果评论在commit中或保存于sonarqube: 静态代

ci持续集成(转)

1.持续集成的组成 用 Ant 或 Maven 等工具建立的自动构建过程 一个代码存储库,比如 CVS 或 Subversion 一个 CI 服务器,比如 Hudson,但是 cron 作业也可以满足需要 们来详细讨论这些组件. 自动的构建 CI 过程会经常集成软件,这需要通过构建来完成.在 Java 环境中,Ant 是常用的构建平台.可以使用 Ant 可靠地自动执行编译.测试等任务,甚至可以执行软件检查和部署.在掌握了 CI 的所有组件之后,您会发现构建策略是成功的 CI 过程最重要的方面.如