关于 Jenkins 的环境变量，可以分为系统内置环境变量和自定义环境变量。系统内置环境变量是 Jenkins 内部定义的环境变量。自定义环境变量是用户自己定义的环境变量 系统环境变量 jenkins 的内置环境变量的查看方式有两种，一种是通过 web url 地址查看，另一种是通过 shell 命令 printenv 查看 方式一:通过地址访问 直接在浏览器中访问 ${YOUR_JENKINS_HOST}/env-vars.html 页面就可以，比如 http://localhost:8080/env-vars.html ，每个变量的用途写的都很清楚 方式二：printenv 通过 shell 命令printenv 获取 pipeline { agent any stages { stage("Env Variables") { steps { sh "printenv" } } } } 通过执行上述 pipeline 的构建，就可以打印出系统内置的环境变量 自定义环境变量 在内置环境变量的基础上，有事我们也需要定义我们自己的的环境变量来方便开发和部署，自定义环境变量的设置分为三种，分别是：声明式，脚本式，内置函数式，接下来分别讲解一下三种方式各是如何设置的。 声明式 声明式定义结构如下： environment { key = value } 声明式可以在 pipeline 的任意阶段声明，看如下示例 pipeline { agent { label any } environment { //全局环境变量 NAME = "zhangsan" } stages { stage('Build') { environment { // 仅在 Build 阶段下有效的环境变量 NAME = "Andy" } steps { sh 'printenv' } } } } 脚本式 脚本式基本结构如下: ...

location 优先级介绍 location 匹配方式有以下几种 location = /path/a/exact.png {}: 精确匹配 location ^~ /path/a/ {}: 优先前缀匹配（符合最长匹配原则） location ~ /Path?/ {} ： 区分大小写正则匹配（首次匹配原则） location ~* /path?/ {} : 不区分大小写正则匹配（首次匹配原则） location /path/a/test.png {} : 前缀匹配（符合最长匹配原则） location 优先级匹配与配置的先后顺序无关，优先级排列顺序如下 精确匹配 > 优先前缀匹配 > 区分大小写正则匹配=不区分大小写正则匹配 > 前缀匹配 实例说明 location = /path/a/exact.png { [ configuration A ] } location ~ /Path?/ { [ configuration B ] } location ~* /path?/ { [ configuration C ] } 如果理解了优先级，将很容易得出如下结论: www.web.com/path/a/exact.png => 匹配 configuration A www.web.com/Path/a => 匹配 configuration B www.web.com/path/a => 匹配 configuration C 当我们发现能够很好的猜测各种 URL 所匹配各个 location 是否心中有些许窃喜，对 location 优先级的理解已经不再话下了？事实并非如此，关于 location 优先级，还有一件事你需要知道。 ...

问题 在同一 server 中同时设置了， a.com, b.com.c.com 三个域名，若三个域名都需要 https 访问，应当如何配置呢？ 示例配置如下： server { listen 443 ssl; server_name a.com b.com c.com; ssl_certificate a.crt; ssl_certificate_key a.key; ... } 问题分析：如果在 ssl_certificate 与 ssl_certificate_key 的配置项中可以增加变量，此问题就可以迎刃而解。 变量 ssl_server_name 经过 goole 发现 nginx 在 1.15.10 及以后的版本支持 ssl_server_name 变量，此变量输出的便是所访问 URL 的 host 部分(不包含端口及后面的 path 部分). URL ssl_server_name https://a.com/test a.com https://b.com:83/test b.com https://c.com/test c.com 有了 ssl_server_name 就可以很好的解决我们在文章开头描述的问题参考配置如下: server { listen 443 ssl; server_name a.com b.com c.com; ssl_certificate /crtPath/$ssl_server_name.crt; ssl_certificate_key /keyPath/$ssl_server_name.key; ... } 配置完成重启服务后，就可以用 https 访问对应的 server_name 了 ...

Composer 是 PHP 的软件包管理系统，它提供用于管理 PHP 软件和依赖库关系的标准格式。作为日常开发，Composer 能够满足我们的日常需求，但有些情况下，我们有些公司内部的扩展，不希望被检索或者放在共有库中，就需要搭建私有库来解决问题。 在讨论搭建私有仓库前，我们先了解一下 Composer 是如何安装扩展的 Composer 安装扩展流程 通过上图我们不难发现，如果要构建私有仓库，我们需要构建一个类似 Packagist 的网站，来告诉 Composer 该从哪里下载扩展代码，这就需要用到 Satis 工具 Satis 介绍 Satis 是一个开源的静态 Composer 仓库生成器，有了它我们可以轻松的构建出一个类似 Packagist 的索引网站，来告诉 Composer 通过我们自己的私有仓库下载扩展。 安装 命令行安装 // 安装 composer create-project composer/satis:dev-main // 构建索引仓库 php bin/satis build <configuration-file> <output-directory> docker 安装 下载镜像： docker pull composer/satis 运行镜像: docker run --rm --init -it \ --user $(id -u):$(id -g) \ --volume $(pwd):/build \ --volume "${COMPOSER_HOME:-$HOME/.composer}:/composer" \ composer/satis build <configuration-file> <output-directory> 配置 创建一个名为：satis.json 的配置文件。 内容如下: ...

随着 nodejs 的兴起，前端开发也进入了 新的时代，webpack 的诞生，更是让其如虎添翼，构建出欣欣向荣的前端生态. 然而事物的发展总是在：发现问题->解决问题->引入新问题中往复。 webpack 给前端带来了一个新的高频操作就是打包，高频的打包会带来如下问题： 阻塞前端工作：前端必须等到打包完成，才能 进入后续工作,如果打包时间过长，这中间就会阻塞就会更加明显。 影响团队协作：当功能点开发完成后，未避免频繁打包，会将多个功能点合并在 一起打包，这样就会导致测试没有办法提前介入测试，如果测试出问题的功能点是在几天前开发的，对于代码已经有所遗忘，还需要阅读代码帮助找回记忆gg。 打断专注时间：如果前端正在专注的解决一个复杂问题,此时出现紧急问题需要打包，使得前端不得不从当前工作中抽身出来进行打包，打包完成后将需要一段时间的预热才可以像之前一样 专注的处理未完成的问题。 对于上述 问题完全可以通过工具构建出一套 CI/CD 方案交由计算机来解决，让前端工程师从打包解放出来。 工具 jenkens: 是一款由 JAVA 编写的开源的持续集成工具. gogs: 轻量级代码仓库 jenkins 与 gogs 的通讯是通过 Gogs plugin 通过 webhook 来通讯的。 方案 方案设计大致如下： 方案执行步骤： 前端工程师往代码仓库 push 代码 gogs 会调用 jenkins 的 webhook 地址触发 jenkins 工作流 jenkins 会将前端代码从代码仓库中拉取最新的代码，并执行构建流程 将构建好的代码上传到 dist 仓库(如果存在 CDN 则清除 CDN 缓存) push dist 仓库到 gogs 远程仓库 gogs 触发 dist 仓库的 webhook,将服务器代码更新到最新的打包文件 完成部署 测试人员执行测试用例（如果由缺陷，将缺陷反馈给前端开发人员） 好处 完成上述方案，前端工程师只需要将前端代码 push 到远程仓库，服务器会自动构建响应的包，并部署到测试服务器上供测试测试,前端可以缩小提交粒度并更快的将功能交付测试，也可以将问题尽早暴露尽早解决。 ...