1. Jmeter 生成测试报告  示例: jmeter -n -t test.jmx -l result.jtl -e -o ./report 成功执行并生成报告: 生成报告失败:注意报告存放目录或测试结果数据(.jtl 文件)必须为空或不存在 打开报告目录下的 index.html 查看执行结果报告: 通过 Error 和断言结果来检查哪些脚本执行失败: 2. Jenkins 配置 1)构建触发器 选择定时任务:如下图所示为每 5 分钟执行该项目 2)构建命令 3)构建后操作 Publish

码云和jenkins的配置流程在Gitee Jenkins Plugin上介绍的很仔细. 附上码云官方Gitee Jenkins Plugin的介绍: https://gitee.com/help/articles/4193#article-header0 是码云基于 GitLab Plugin 开发的 Jenkins 插件.用于配置 Jenkins 触发器,接受码云平台发送的 WebHook 触发 Jenkins 进行自动化持续集成或持续部署,并可将构建状态反馈回码云平台. 邮件通知 Emai

通过前面两篇文章,我们已经有了一个"嗷嗷待哺"的K8s集群环境,也对相关的概念与组件有了一个基本了解(前期对概念有个印象即可,因为只有实践了才能对其有深入理解,所谓"纸上得来终觉浅,绝知此事要躬行"),本文从实践角度介绍如何结合我们常用的Gitlab与Jenkins,通过K8s来实现项目的自动化部署,示例将包括基于SpringBoot的服务端项目与基于Vue.js的Web项目. 本文涉及到的工具与技术包括: Gitlab -- 常用的源代码管理系统 Jenkins,

如果你还想从头学起 Docker,可以看看这个系列的文章哦! https://www.cnblogs.com/poloyy/category/1870863.html 搭建 Jenkins 容器 就是实战第一篇文章:https://www.cnblogs.com/poloyy/p/13954637.html Jenkins 初始化流程 访问 Jenkins 查看本机 IP ifconfig6·rtyjie 查看容器运行端口 docker ps 我的是用主机 80 端口映射到容器的 8080 端口

前言第一部分:Pycharm for Gitee1. pycharm安装gitee插件2. gitee关联本地Git快速设置- 如果你知道该怎么操作,直接使用下面的地址简易的命令行入门教程:3. Git关联远程仓库第二部分:Jenkins for Gitee(一)简介1. 目前支持特性:2. 计划中特性(二)插件安装(三)插件配置1. 添加Gitee链接配置2. 新建构建任务3. 任务全局配置4. 源码管理配置5. 触发器配置6. 构建后步骤配置7. 构建结果回评至Gitee8. 构建成功自动合

前言 Gitea 是一个用于代码托管的轻量级单体程序,它能与现有的经典应用集成,诸如代码分析工具 SonarQube.持续集成工具 Drone.Jenkins 以及用于工单管理的客户端插件(VSCode.Jenkins IDE). 不久之后,Gitea 也将迎来自身集成的一体化 CI/CD 功能. 今天要介绍的是 Gitea 与 Jenkins CI/CD 的集成. 关于 Jenkins Jenkins 是一款开源的.提供友好操作界面的持续集成(CI)工具,在国内外都有众多的使用者.Jenkin

下载所需插件,系统设置-->插件管理,搜索以下两个插件,选择安装 登录gitLab,生成一个Personal Access Tokens 进入Jenkins,添加api token,路径:首页-->凭据-->添加凭据 添加后再次打开,如图所示 然后打开系统管理,进入系统设置,配置gitLab 然后进入job,进行配置 进入GitLab,打开项目-->settings 测试成功,返回200 到此,触发器配置成功,开发一旦有提交代码,就会自动构建,如图所示 Ps:遇到的问题:gitLa

Jenkins 有三种类型的构建触发器,如下图: Build after other projects are built:在其他项目构建后构建: Build periodically:定时构建: Poll SCM:定时检查代码更新,如果有更新则构建. 其中“Build periodically”和“Poll SCM”使用的是Cron,帮助文档如下: This field follows the syntax of cron (with minor differences). Specifica

   我们在执行Jenkins的项目构建的时候一般都是通过web管理界面中的”构建”来执行项目构建操作,但是除此之外我们还可以通过项目配置中的”构建触发器”来触发构建操作, 其中”构建触发器”有一种方式是通过配置令牌远程触发项目构建: 要启用Token(令牌)远程触发项目构建首先要保证Jenkins服务安装了build-token-root 插件,并且配置了Jenkins的身份验证(不是必须). 打开项目的配置: 设置令牌: 在浏览器中输入: http://IP:8080/jenkins/job

转至博客:上海-悠悠 前言 跑自动化用例每次用手工点击jenkins出发自动化用例太麻烦了,我们希望能每天固定时间跑,这样就不用管了,坐等收测试报告结果就行. 一.定时构建语法 * * * * * (五颗星,中间用空格隔开) 第一颗*表示分钟,取值0~59第二颗*表示小时,取值0~23第三颗*表示一个月的第几天,取值1~31第四颗*表示第几月,取值1~12第五颗*表示一周中的第几天,取值0~7,其中0和7代表的都是周日 1.每30分钟构建一次: H/30 * * * * 2.每2个小时构建一次

构建触发器,实现当gitlab有push动作时候,jenkins自动拉代码. 拉取gitlab代码库: jenkins安装git插件 配置gitlab服务器和jenkins服务器身份互信 jenkins服务器生成一对rsa key. 复制公钥到gitlab web dashboard添加 在jenkins Credentials里添加private key. 接下去创建project 拉取到了本地: /var/lib/jenkins/workspace 安装两个插件 Gitlab Hook Pl

邮件触发类型介绍(Triggers) By default, the onlytrigger configured is the "Failure" trigger.  To add moretriggers, select one from the dropdown, and it will be added to the list. Once you have added a trigger, you have several options.  If you click &quo

如上图所示,Jenkins通常通过点击“立即构建”来进行手动构建项目,其实也可以使用配置中的 Poll SCM和Build periodically来进行定时自动构建项目: 在“配置”——>“构建触发器”中,如下图所示: Build after other projects are built:在其他项目触发的时候触发,里面有分为三种情况,也就是其他项目构建成功.失败.或者不稳定的时候触发项目: Poll SCM:定时检查源码变更(根据SCM软件的版本号),如果有更新就checkout最新cod

利用jenkins的远程构建功能,我们可以使用任何脚本,甚至定制一个Web页来控制Job的执行,但是远程构建你如果直接使用的话,老是需要登录才能执行,如何避免登录?稍微折腾了一下,调通了. 1.首先去系统管理->管理插件里边,搜索并安装插件 Build Authorization Token Root Plugin,不会安装插件的先去搜一下,安装好后如下图: 2.然后点击右上角,你登录的用户名,再点击设置,找到API Token,复制下来你这个用户的Token,用于远程访问Job用. 3.找到你

利用jenkins的远程构建功能,我们可以使用任何脚本,甚至定制一个Web页来控制Job的执行,但是远程构建你如果直接使用的话,老是需要登录才能执行,如何避免登录?稍微折腾了一下,调通了. 1.首先去系统管理->管理插件里边,搜索并安装插件 Build Authorization Token Root Plugin,不会安装插件的先去搜一下,安装好后如下图: 2.然后点击右上角,你登录的用户名,再点击设置,找到API Token,复制下来你这个用户的Token,用于远程访问Job用. 3.找到你

触发器说明 build whenever a snapshot dependency is built,当job依赖的快照版本被build时,执行本job. 触发远程构建 (例如,使用脚本):这里使用于自动化构建,拼接url后写入代码中可以实现在脚本或者工具执行构建 build after other projects are built,当本job依赖的job被build时,执行本job Trigger only if build is stable:只有在构建稳定时才触发 Trigger e

构建触发器配置,当你在文本框中输入配置的时间后,文本框下方会有时间解释,这样可以很好的看到自己配置的时间对不对. 可以清晰看到我的配置第一个运行时间是周五上午10点执行,第二次是星期六上午10点.     1.Build periodic ally与Poll SCM Build periodic ally:周期性的执行,源码有没有变化都会执行 比如配置:H/60 * * * *  这样配置就会每60分钟构建一次,不管SVN有没有新源码 Poll SCM:定时行的执行,源码有变化才会执行 比如配置

一.覆盖率定义 作为一个测试人员,保证产品的软件质量是其工作首要目标,为了这个目标,测试人员常常会通过很多手段或工具来加以保证,覆盖率就是其中一环比较重要的环节. 我们通常会将测试覆盖率分为两个部分,即“需求覆盖率”和“代码覆盖率”. 需求覆盖:指的是测试人员对需求的了解程度,根据需求的可测试性来拆分成各个子需求点,来编写相应的测试用例,最终建立一个需求和用例的映射关系,以用例的测试结果来验证需求的实现,可以理解为黑盒覆盖. 代码覆盖:为了更加全面的覆盖,我们可能还需要理解被测程序的逻辑,需要考

一.定时构建 Build periodically:定时执行构建任务,不管远程代码分支上的代码是否发生变化,都执行一次构建. 语法:* * * * *(五颗星,中间用空格隔开) 第一个:分钟,取值0~59 第二个:小时,取值0~23 第三个:天,取值1~31 第四个:月,取值1~12 第五个:星期,取值0~7,0和7都表示星期天 (1)H/20 * * * * (每30分钟构建一次) (2)H H/2 * * * (每2小时构建一次) (3)0 8 * * * (每天8点构建一次) (4)0 8

Poll SCM:定时检查源码变更(根据SCM软件的版本号),如果有更新就checkout最新code下来,然后执行构建动作.我的配置如下: */5 * * * * (每5分钟检查一次源码变化) Build periodically:周期进行项目构建(它不care源码是否发生变化),我的配置如下: 0 2 * * * (每天2:00 必须build一次源码)

build whenever a snapshot dependency is built 当job依赖的快照版本被build时,执行本job. build after other projects are built 当本job依赖的job被build时,执行本job 这里又分三种情况: ①Trigger only if build is stable:其他项目构建成功 ②Trigger even if the build is unstable:其他项目不稳定 ③Trigger even i