Jenkins

Jenkins 插件名称高频关键词有哪些？一切尽在酷炫多彩的词云图 作为最流行的 CI/CD 工具，Jenkins 的优势之一是其生态强大，而这与其插件体系分不开的。 目前 Jenkins 插件 1500+ （截止2020年06月17日，插件数量为1749）。 近日发现词云比较好玩，于是想着以 Jenkins 插件名称为数据源，形成的词云会是什么样的呢，什么关键字会比较突出呢？ 想到就去做，带着问题，带着好奇心，开始了实践之旅～ 插件基本字段说明 以 Jenkins 中文本地化插件为例，在 Jenkins 官网插件详情页面可以看出： 其 ID 为 localization-zh-cn，Name 为 Localization: Chinese (Simplified)。 获取所有 Jenkins 插件的名称 如何获取所有 Jenkins 插件的名称呢？这里我想到3种方式，或许还有更多方式： 插件官网 爬虫抓取 插件权限文件 获取 插件更新中心配置文件 获取 对比上面的三种方式，插件权限文件中并没有 Name 字段，插件更新中心配置文件相对从插件官网抓取比较简单。 所以计划从 update-center.json 进行解析，其中插件名称在 json 中对应字段为 title。 生成 Jenkins 插件名称文件 读取 update-center.json 中 plugin 的

jenkins如何同通过SCM定时轮询构建github代码 我当前的centos，安装步骤如下： 1、wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo 2、rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key 3、yum install -y jenkins 4、启动jenkins 命令：service jenkins start 启动成功后如图 然后通过ip+端口访问 http://81.70.13.149:8080/ 注意：第一次进入的时候需要添加密码，密码路径在 cat /var/lib/jenkins/secrets/initialAdminPassword 点击第一个 进入后选择新建一个任务，如图所示 点击保存，保存后如图所示 将这个地址粘贴到这里 接下来 点击保存后过一分钟将会看到从github拉取代码 看到了，这个就是jenkins构建的一个流程，小伙伴试试吧 来源： oschina 链接： https://my.oschina.net/u/4365679/blog/4671468

坚持原创输出，点击蓝字关注我吧 作者：清菡 博客：知乎、博客园、思否、云+社区等平台搜索 清菡或者清菡软件测试 就能找到作者。 目录 一、持续集成流程 二、持续集成的好处 三、需理解几个 Jenkins 的概念 1.Jenkins 的工作空间目录怎么改 2.怕历史数据占用内存太多如何配置 四、Master/Slave 模式 五、其它好玩的配置 一、持续集成流程 正式接收开发转过来的包之前，先从 svn 上下载代码，给它做次静态代码检查，然后编译打包。可以在开发的服务器或者自己的服务器运行单元测试文件。单元测试后，没用什么大的 bug，再部署到测试环境中。测试环境部署完成后先做冒烟测试，尽快看看主流程有没有问题。如果冒烟测试没问题就做回归测试。当然 Jenkins 也可以做其它事情。 以上 6 个流程，能不能都做得到，都是看公司情况来决定的。 代码检查有 2 种方式，开发自己检查代码叫做代码走查，静态代码检查是 Jenkins 自动执行的。 二、持续集成的好处 本地环境什么都有，所以开发打包完全没问题。但是把它丢到另外一个环境中就容易出现缺少依赖包的情况，因为别的环境没有，本机是有的。 如果用机器，会在代码中标明哪些包必须有，哪些包必须引进来。因为有编译脚本，编译脚本中必须依赖第三方的包，打包的时候就要注意。打包的代码也是测试写的，打包的时候应该把哪些文件下面的包全部打进来

curl 访问最新版jenkins api 报 Error 403 No valid crumb was included in the request 解决办法 Using cURL The following example retrieves a crumb and uses it to build a job called someJob . Before 2.176.2, no session required: # Replace with your Jenkins URL and admin credentials SERVER= "http://localhost:8080" CRUMB=$(curl -u "admin:admin" "$SERVER" /crumbIssuer/api/xml?xpath=concat\( //crumb RequestField,%22:%22, //crumb \)) curl -X POST -u "admin:admin" -H "$CRUMB" "$SERVER" /job/someJob/build After 2.176.2, session is required: # Replace with your Jenkins URL and admin credentials SERVER= "http:/

容器化背景 本来生活网（ benlai.com ）是一家生鲜电商平台，公司很早就停止了烧钱模式，开始追求盈利。既然要把利润最大化，那就要开源节流，作为技术可以在省钱的方面想想办法 。我们的生产环境是由 IDC 机房的 100 多台物理机所组成，占用率高达 95%，闲置资源比较多，于是我们考虑借助 k8s 来重构我们的基础设施，提高我们资源的利用率。 容器化项目团队最初加上我就只有三个人，同时我们还有各自的工作任务要做，留给容器化的时间较少，因此我们要考虑如何快速的搭建容器平台，避免走全部自研这条路，这对我们来说是个巨大的挑战。在经历了一年的容器化之旅后，分享下我们这一年所踩过的坑和获得的经验。 面临的问题 在搭建 k8s 集群前，有很多问题摆在我们面前： l 人手不足，时间也不充裕，不能有太多自研的需求 l 我们目前的发布是由测试人员完成的，不可能要求他们去写一个 yaml 或执行 kubectl 做发布，这个学习成本太高也容易出错，因此我们必须构建一个用户体验良好的可视化平台给发布人员使用 l 我们有大量的 .NET 项目，而 .NET 环境又依赖 Windows l ConfigMap/Secret 不支持版本控制，同时用来存业务配置也不是很方便 l k8s 集群和外部的通信如何打通 容器平台 作为小团队去构建一个容器平台，自研的工作量太大了。前期我们调研过很多可视化平台，比如

我的职业生涯开始和大多数测试人一样，开始接触都是纯功能界面测试。那时候在一家电商公司做测试，做了有一段时间，熟悉产品的业务流程以及熟练测试工作流程规范之后，效率提高了，工作比较轻松，也得到了更好的机会去发展。 在后来的公司得到了领导的信任，待遇方面工资加上年终奖，加起来年薪能达到20W。由于当时公司规模和产品的局限性，导致自动化测试始终未能应用到公司项目中。外面的世界很大，自动化已经流行而且越来越普及，内心经过一番抉择后，我更想要突破自己的技术瓶颈，所以选择顶住了压力，跳槽到一家公司专职做自动化测试工作。通过不断的项目经历和机会，我将公司产品前后端的自动化测试全部落地实现。 那些自动化脚本真正成为了公司资产，每次上线回归带来的收益远超出我的预期。并且定时在公司的技术分享会展示效果，那种从0到1的成就感非常难忘。后面负责自动化测试团队工作，核心框架搭建。学习用到的技术栈：包括Python、Selenium、RF、Requests、Jenkins、以及见识到先进主流的Docker容器技术，持续集成 从手工到自动化测试/测试开发，给我带来的帮助不仅仅是20W到40W，待遇上面的提高，包括做自动化测试遇到的坑，解决问题的思路，以及技术瓶颈的突破，形成一套知识框架体系，得到一套有效落地的自动化测试方案。 目前测试平台项目研发已经完成，并且在Github开源，有兴趣的朋友可以去Github下载