Jenkins

docker安装Jenkins

无人久伴 提交于 2020-07-27 12:14:59
docker 安装 Jenkins docker search jenkins docker pull jenkins/jenkins:lts mkdir /opt/apps/jenkins -p chmod 777 /opt/apps/jenkins ll /opt/apps/ docker run -it --name wk-jenkins -v /opt/apps/jenkins:/var/jenkins_home -p 8080:8080 -p 50000:50000 -p 45000:45000 jenkins/jenkins:lts ## 查看启动状态 dockeer ps ## 查看启动端口 netstat -ntlp |grep 8080 ## 浏览器访问 ip:8080 ## 参考网址:https://kefeng.wang/2017/01/06/jenkins/ 修改默认插件升级网址 ## 升级站点项的的地址配置文件 cat hudson.model.UpdateCenter.xml ## 备份配置文件 cp hudson.model.UpdateCenter.xml hudson.model.UpdateCenter.xml.default ## 【系统管理】【管理插件】【高级】升级站点项的地址修改成, ## 手动修改配置文件或后台修改http://ip

软件测试面试题(2)

柔情痞子 提交于 2020-07-27 08:28:55
  经过前面总结的面试题,看到留言和私信都觉得还不错,这里安静在总结一些亲身经历的面试题 1、启动多个app同时运行用例怎么做?代码如何实现? 通过python进行对启动命令行appium进行封装,然后通过多线程的方法进行启动appium进行执行多台手机操作。具体代码: appium---多线程启动app(多台设备启动app) 2、unittest如何操作它的执行顺序 unittest本身执行是无序的,我们可以通过进行创建名称是进行判断执行顺序,也可以通过unittest中的TestSuite来进行添加执行的用例。具体操作: unittest---unittest多种加载用例方法 3、unittest中能否进行更改执行规则?不已test开头的方式? 我们如果仔细阅读过unittest的方法就可以发现,其实是可以进行在源码中修改的。 4、postman中的断言如何操作? postman的断言是通过javaScript来编写的,postman中有个Tests,我们可以在里面进行添加断言,也可以通过javaScript代码进行自己编写断言。具体操作: postman---postman增加断言 5、unittest的弊端? unittest目前不支持用例失败重跑,需要进行二次开发 6、通过学生,班级,科目,分数,学期这些你如何创建数据表? 这里可能就考察数据库的能力和业务逻辑流程了

如何学习自动化测试?——手工测试转向自动化测试?

浪子不回头ぞ 提交于 2020-07-27 04:10:10
我在百度搜索了一个问题,自动化测试——这个是关键词。跳出来的一个问题:如何学习自动化测试?我觉得这个文章写得很不错,我就转载加入自己对于自动化测试的一些想法,写下来分享给大家。希望对测试人有帮助。 问: 作为一个测试人员,从业年期从事手工测试的工作是没有太多坏处的,当然,如果一直点来点去那么确实自身得不到提高,这时候选择学习自动化测试是一件很有必要的事情,一来将自己从繁重的重复工作中解放出来,从事一些更有挑战的工作,二来能积累技术知识,厚积薄发完成飞跃,那么技术新人该如何学习自动化测试呢? (看得出来提问的朋友,和我们很多的朋友都是有一样的情况,就是对于如何学习自动化测试有些迷茫) 1.万事开头难,希望你可以勇于踏出第一步,学习python基本语法。 2.到国内一些可以做练习的网站。(链接就不放了,可以百度) 学习HTML/CSS下的html、xml、webservice三个教程。 3. 然后下一个python的requests库学习写最简单的网络爬虫。博客园、知乎上爬虫教程一大堆。这一步是一个转折点,会有一种有点懂但又不是很开窍的意思。写简单的东西有一定的成就感,但是有不知道复杂的接口的缘由,同时还学到了怎么解析一个页面。 4.学习Python的测试框架unittest,了解一下怎么用unittest和python的mock模块写一个小单元测试。 5.把3和4结合起来

jenkins更换清华源

放肆的年华 提交于 2020-07-27 03:57:19
[root@localhost ~]# find / -name "default.json" /var/lib/jenkins/updates/default.json [root@localhost ~]# sed -i 's/http:\/\/updates.jenkins-ci.org\/download/https:\/\/mirrors.tuna.tsinghua.edu.cn\/jenkins/g' /var/lib/jenkins/updates/default.json && sed -i 's/http:\/\/www.google.com/https:\/\/www.baidu.com/g' /var/lib/jenkins/updates/default.json [root@localhost ~]# service jenkins restart 来源: oschina 链接: https://my.oschina.net/520wsl/blog/4365880

如何使用Jenkins Pipeline 获取git commit id

跟風遠走 提交于 2020-07-26 05:37:03
如何使用Jenkins Pipeline 获取git commit id? 需求:jenkins pipeline获取git commit id 作为docker中imagesTag标识 解决方法: 使用git方法获取commit id git rev-parse HEAD (完整) 或者 git rev-parse --short HEAD (简短) 出处: https://www.cnblogs.com/liucx/ Pipeline中 script { env.imageTag = sh (script: 'git rev-parse --short HEAD ${GIT_COMMIT}', returnStdout: true).trim() } 在管道脚本中就可以直接使用:${imageTag} 即可获取到commit id, 如能解决您的问题,请帮忙点个小心心 // https://www.cnblogs.com/liucx 你也可以获取的提交ID的提交消息,并将其设置为环境变量 stage('get_commit_msg') { steps { script { env.GIT_COMMIT_MSG = sh (script: 'git log -1 --pretty=%B ${GIT_COMMIT}', returnStdout: true).trim() } }

Jenkins构建步骤图解

家住魔仙堡 提交于 2020-07-26 00:21:27
Jenkins是什么 Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具,起源于Hudson(Hudson是商用的),主要用于持续、自动的构建/测试软件项目、监控外部任务的运行(这个比较抽象,暂且写上,不做解释)。Jenkins用Java语言编写,可在Tomcat等流行的servlet容器中运行,也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT,构建工具有Maven、Ant、Gradle。 使用Jenkins对Java代码进行打包 Jenkins是一个强大的CI工具,虽然本身使用Java开发,但也能用来做其他语言开发的项目CI。下面讲解如何使用Jenkins创建一个构建任务。 1. 登录Jenkins,点击新建任务 之后进入到这个界面,任务名称可以自行设定,但需要全局唯一。输入名称后选择构建一个自由风格的软件项目(有时选择第二个:构建一个maven项目),并点击下方的确定按钮即创建了一个构建任务,然后就会自动跳转到该job的配置页面。 2. 配置界面,配置项详解 2.1 General :是构建任务的一些基本配置。名称,描述之类的。 2.2 源码管理 :源码管理就是配置你代码的存放位置。 2.3 构建触发器 :顾名思义,就是构建任务的触发器。 2.4 构建环境 :就是构建之前的一些准备工作,如指定构建工具。

聊聊 Python 代码覆盖率工具

寵の児 提交于 2020-07-25 10:54:56
点击上方“ AirPython ”,选择“ 加为星标 ” 第一时间关注 Python 技术干货! 1. 代码覆盖率 单元测试代码覆盖率作为一种度量方式,可以计算单元测试用例对于被测代码的覆盖程度,即:被执行的代码数量和代码总数量的比值 统计代码覆盖率 ,经常在单元测试后再进行,可以为测试结果提供评判依据 Python 项目最常使用的代码覆盖率统计工具就是: C overage 2. Coverage Coverage 是用于统计 Python 代码覆盖率的工具,不仅支持分支覆盖率统计,生成 HTML 格式的统计报告,而且可以集成到 Jenkins 中使用 安装 Coverage 依赖同样是使用 pip 安装 # 安装 Coverage 依赖 pip3 install coverage Coverage 官方提供了 2 种方式,用于统计代码覆盖率,分别是: 1、Coverage 命令行 2、Coverage API 更详细的介绍可以参考官方文档: https://coverage.readthedocs.io/en/latest/ 3. 实战一下 首先,用 Python 编写一段简单被测代码,如下: # 被测代码 # main.py def get_level (cource) : """ 自定义的方法 :param cource:成绩 :return: """ if cource

Dockerfile+Jenkinsfile+GitLab轻松实现.NetCore程序的CI&CD

你说的曾经没有我的故事 提交于 2020-07-24 19:59:31
一.相关介绍 Dockerfile:关于Dockerfile的使用说明,我在文章《 让.NetCore程序跑在任何有docker的地方 》中有说到,这里不在赘述,需要的可以先看下,本文主要介绍Jenkinsfile结合dockerfile配合使用,自动构建.NetCore应用程序。 Jenkinsfile :Jenkinsfile 是 Jenkins 2.x 或更高版本核心特性 Pipeline(流水线) 的脚本,或者说对于Jenkins 流水线的定义被写在一个叫Jenkinsfile的文本文件中,该文件可以被提交到项目的源代码的控制仓库。这是"流水线即代码"的基础; 将CD 流水线作为应用程序的一部分,像其他代码一样进行版本化和审查。 创建 `Jenkinsfile`并提交它到源代码控制中提供了以下几个好处: 自动地为所有分支创建流水线构建过程并拉取请求。 在流水线上代码复查/迭代 (以及剩余的源代码)。 对流水线进行审计跟踪。 该流水线的真正的源代码 , 可以被项目的多个成员查看和编辑。 Jenkinsfile 能使用两种语法进行编写,分别是“声明式”和“脚本化”,二者语法都是 DSL(Domain-specific language) 语言,二者语法差不多,下面我们具体看下 二 .Jenkins和GitLab的安装 工欲善其事,必先利其器

全网首发!Spring Cloud微服务架构实战派39个实例+1个综合项目

爱⌒轻易说出口 提交于 2020-07-24 17:29:08
内容摘要: 这份文档针对 Spring Cloud Greenwich.SR2版本+Spring Boot的2.1.x.RELEASE版本。 在编写过程中,不仅考虑到在企业任职所需的技能,还考虑到求职面试时可能会遇到的知识点。 本书采用 “知识点+实例” 形式编写,共有 “39个基于知识点的实例 + 1个综合性项目” ,深入讲解了Spring Cloud的各类组件、微服务架构的解决方案和开发实践,以及容器、Kubernetes和Jenkins等DevOps(开发运维一体化)相关知识。 介绍每一个知识点的主脉络是:它是什么、为什么用、怎样用、为什么要这样用、如何用得更好、有什么最佳的实践。 适合具备 Java基础的开发人员、对微服务架构和Spring Cloud感兴趣的读者、了解Spring或Spring Boot的开发人员 自学之用。 需要获取这份PDF的小伙伴直接添加小助理vx:kaixindian331即可免费获取! 第一篇入门 第1章进入微服务世界 第2章准备开发环境和工具 第3章实例1:用Spring cloud实现—个微服务系统 第二篇基础 第4章认识微服务 第5章Spring Cloud基础 第三篇进阶 第6章用Consul实现服务治理 第7章用Ribbon和Feign实现客户端负载均衡和服务调用 第8章用Hystrix实现容错处理 第9章用Spring Cloud

Jenkins 中以构建 Tag 来实现版本管理

浪尽此生 提交于 2020-07-24 12:45:12
好的工具和流程能使我们事半功倍,而这个过程是不断迭代和演进的。关于这一块的内容,之前写过几篇文章: 在团队中使用GitLab中的Merge Request工作模式 敏捷下的需求和代码分支管理 不断进化的分支和需求管理 现在又有了些新的变化和改进,之所以需要改进,肯定是遇到问题了,那么就先从问题来开始今天的文章。 问题 问题分为两种: 方法论的问题 :比如团队采用主干开发,主干发布的模式,但是质量得不到保证,这时通过分析讨论决定采用采用主干开发,分支发布的模式来解决,这属于从方法论层面解决问题。 落地执行的问题 :已经知道应该采用主干开发,分支发布的模式,但在实际操作的时候,难以执行下去,这属于执行的问题。 在《不断进化的分支和需求管理》一文的最后提到会引入 release 分支和 tag,实际也这么做了,但效果并不理想,原因是执行的不严格,没有做到位,具体原因如下: 发布时是对分支进行构建发布,发布后再在 GitLab 中打上 tag,一忙起来很容易忘记; 镜像的版本也是如此。 解决思路 目的其实很简单,就是让代码的 tag 和镜像的 tag 能够一致,靠人工去做这些事情比想象的要更加困难,所以稍微转换了下思路就能实现自动化,也就可以解决这个问题。 之前提到的 release 分支只做最终的集成测试; 需要发布时就从 release 分支创建 tag,对 tag 来做发布