Jenkins Pipeline - set and use environment variables

Jenkins Pipeline - set and use environment variables

How to list the environment variables available to Jenkins Pipeline examples/jenkins/list_environment.Jenkinsfile pipeline { agent none environment { color = "blue" } stages { stage('first') { agent { label 'master' } steps { sh "printenv | sort" } } } }   In this example we list the environment variables using the printenv command of Unix/Linux which we pipe through the Unix sort command so we'll see the environment variables in a sorted list. We invoke it using the sh command of the Jenkins Pipeline. Before we do that we set a new variable called "color" in the environment section of the Jenkins Pipeline. On Unix/Linux: sh('printenv | sort') On Windows you could run: bat('set') The output will looks something like this: BUILD_DISPLAY_NAME=#18 BUILD_ID=18 BUILD_NUMBER=18 BUILD_TAG=jenkins-list_environment_variables-18 BUILD_URL=http://localhost:8080/job/list_environment_variables/18/ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/110/bus EXECUTOR_NUMBER=1 HOME=/var/lib/jenkins HUDSON_COOKIE=40cd788e-91bd-4ebd-86c9-c10333fa27a9 HUDSON_HOME=/var/lib/jenkins HUDSON_SERVER_COOKIE=912830efeb6e2316 HUDSON_URL=http://localhost:8080/ JENKINS_HOME=/var/lib/jenkins JENKINS_NODE_COOKIE=dbf878e6-0ae5-4ffe-a32c-aa7876f975ce JENKINS_SERVER_COOKIE=durable-f6e3ca8e5d2310d4d5695d128db1ea2f JENKINS_URL=http://localhost:8080/ JOB_BASE_NAME=list_environment_variables JOB_DISPLAY_URL=http://localhost:8080/job/list_environment_variables/display/redirect JOB_NAME=list_environment_variables JOB_URL=http://localhost:8080/job/list_environment_variables/ LANG=C.UTF-8 LOGNAME=jenkins MAIL=/var/mail/jenkins NODE_LABELS=master NODE_NAME=master PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin PWD=/var/lib/jenkins/workspace/list_environment_variables RUN_CHANGES_DISPLAY_URL=http://localhost:8080/job/list_environment_variables/18/display/redirect?page=changes RUN_DISPLAY_URL=http://local

【HTTP】GET传参最大长度的理解误区

【HTTP】GET传参最大长度的理解误区

零、总结 文章数据来源于网络,可能存在变动,但是原理是一样的。 HTTP 协议 未规定 GET 和POST的长度限制 GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度 不同的浏览器和WEB服务器,限制的最大长度不一样 要支持IE,则最大长度为2083byte,若只支持Chrome,则最大长度 8182byte 一、误解 大家都知道http 中 存在 GET 和 POST 这两种最常用的请求方式。(PUT,DELETE不在本文讨论范围之内) 误解:HTTP 协议下的 Get 请求参数长度是有大小限制的,最大不能超过XX,而 Post 是无限制的。 1、首先即使有长度限制,也是限制的是整个 URI 长度,而不仅仅是你的参数值数据长度。 2、HTTP 协议从未规定 GET/POST 的请求长度限制是多少。 **以下内容摘自 《关于 HTTP GET/POST 请求参数长度最大值的一个理解误区》, 文章时间为 2013年的。可能以当前最新的浏览器有出入 ** The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. 3、所谓的请求长度限制是由浏览器和 web 服务器决定和设置的,各种浏览器和 web 服务器的设定 均不一样,这依赖于各个浏览器厂家的规定或者可以根据 web 服务器的处理能力来设定。 The limit is in MSIE and Safari about 2KB, in Opera about 4KB and in Firefox about 8KB, (255 bytes if we count very old browsers) . We may thus assume that 8KB is the maximum possible length and that 2KB is a more affordable length to rely on at the server side and that 255 bytes is the safest length to assume that the entire URL will come in. If the limit is exceeded in either the browser or the server, most will just truncate the characters outside the limit without any warning. Some servers however may send a HTTP 414 error. If you nee

Github开源后台管理模板10个

Github开源后台管理模板10个

Web 开发中几乎所有的平台都需要一个后台管理,但是从零开发一套后台控制面板并不容易,幸运的是有很多开源免费的后台控制面板可以给开发者使用,那么有哪些优秀的开源免费的控制面板呢?我在 Github 上收集了一些优秀的后台控制面板,并总结得出 Top 10。 AdminLTE Github Star 数 24969 , Github 地址:https://github.com/almasaeed2010/AdminLTE。 非常流行的基于 Bootstrap 3.x 的免费的后台 UI 框架。 vue-Element-Admin Github Star 数 19546, Github 地址:https://github.com/PanJiaChen/vue-element-admin。 一个基于 vue2.0 和 Eelement 的控制面板 UI 框架。 tabler Github Star 数 15870, Github 地址:https://github.com/tabler/tabler。 构建在 BootStrap 4 之上的免费的 HTML 控制面板框架 Gentelella Github Star 数 15654, Github 地址:https://github.com/puikinsh/gentelella。 一个基于 Bootstarp 的免费的后台控制面板。 ng2-admin Github Star 数 13181, Github 地址:https://github.com/akveo/ngx-admin。 基于 Angular 2, Bootstrap 4 和 Webpack 的后台管理面板框架。 ant-design-pro Github Star 数 12707,Github 地址:https://github.com/ant-design/ant-design-pro。 开箱即用的中台前端/设计解决方案 blur-admin Github Star 数 9241,Github 地址:https://github.com/akveo/blur-admin。 基于 Angular 和 Bootstrap 的后台管理面板框架。 vue-admin Github Star 数 8676,Github 地址:https://github.com/vue-bulma/vue-admin。 基于 Vue 和 Bulma 的控制面板。 iview-admin Github Star 数 8668,Github 地址:https://github.com/iview/iview-admin。 基于 iView 的 Vue 2.0 控制面板。 material-dashboard Github Star 数 7111,Github 地址:https://github.com/creativetimofficial/material-dashboard。 基于 Bootstrap 4 和 Material 风格的控制面板。

数据库连接池到底应该设多大?这篇文章可能会颠覆你的认知

数据库连接池到底应该设多大?这篇文章可能会颠覆你的认知

本文内容95%译自这篇文章:https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing 我在研究HikariCP(一个数据库连接池)时无意间在HikariCP的Github wiki上看到了一篇文章(即前面给出的链接),这篇文章有力地消除了我一直以来的疑虑,看完之后感觉神清气爽。故在此做译文分享。 接下来是正文 数据库连接池的配置是开发者们常常搞出坑的地方,在配置数据库连接池时,有几个可以说是和直觉背道而驰的原则需要明确。 1万并发用户访问 想象你有一个网站,压力虽然还没到Facebook那个级别,但也有个1万上下的并发访问——也就是说差不多2万左右的TPS。那么这个网站的数据库连接池应该设置成多大呢?结果可能会让你惊讶,因为这个问题的正确问法是: “这个网站的数据库连接池应该设置成多小呢?” 下面这个视频是Oracle Real World Performance Group发布的,请先看完: http://www.dailymotion.com/video/x2s8uec (因为这视频是英文解说且没有字幕,我替大家做一下简单的概括:) 视频中对Oracle数据库进行压力测试,9600并发线程进行数据库操作,每两次访问数据库的操作之间sleep 550ms,一开始设置的中间件线程池大小为2048: 初始的配置 压测跑起来之后是这个样子的: 2048连接时的性能数据 每个请求要在连接池队列里等待33ms,获得连接后执行SQL需要77ms 此时数据库的等待事件是这个熊样的: 各种buffer busy waits 各种buffer busy waits,数据库CPU在95%左右(这张图里没截到CPU) 接下来,把中间件连接池减到1024(并发什么的都不变),性能数据变成了这样: 连接池降到1024后 获取链接等待时长没怎么变,但是执行SQL的耗时减少了。 下面这张图,上半部分是wait,下半部分是吞吐量 wait和吞吐量 能看到,中间件连接池从2048减半之后,吐吞量没变,但wait事件减少了一半。 接下来,把数据库连接池减到96,并发线程数仍然是9600不变。 96个连接时的性能数据 队列平均等待1ms,执行SQL平均耗时2ms。 image.png wait事件几乎没了,吞吐量上升。 没有调整任何其他东西,仅仅只是缩小了中间件层的数据库连接池,就把请求响应时间从100ms左右缩短到了3ms。 But why? 为什么nginx只用4个线程发挥出的性能就大大超越了100个进程的Apache HTTPD?回想一下计算机科学的基础知识,答案其实是很明显的。 即使是单核CPU的计算机也能“同时”运行数百个线程。但我们都[应该]知道这只不过是操作系统用时间分片玩的一个小把戏。一颗CPU核心同一

Elasticsearch 可视化管理工具

Elasticsearch 可视化管理工具

Elasticsearch 简介 Elasticsearch 是一个分布式的开源搜索和分析引擎,适用于所有类型的数据,包括文本、数字、地理空间、结构化和非结构化数据。 Elasticsearch 虽然可以通过 RESTful API 操作,但是使用还是比较麻烦,下文介绍几个常用的可视化管理工具。 PS: 下面是Elasticsearch 部署 与 RESTful API 常用操作 Docker-compose 部署 ELK Elasticsearch RESTful API 常用操作 ElasticHD ElasticHD 支持 ES监控、实时搜索、Index template快捷替换修改、索引列表信息查看, SQL converts to DSL工具等。是一款非常伴的 Dashboard。 项目地址:https://github.com/360EntSecGroup-Skylar/ElasticHD Docker 安装: $ docker run -p 9200:9200 -d --name elasticsearch elasticsearch $ docker run -p 9800:9800 -d --link elasticsearch:demo containerize/elastichd Open http://localhost:9800 in Browser Connect with http://demo:9200 ElasticHD Dashboard 展示: elasticsearch-head elasticsearch-head 是用于监控 Elasticsearch 状态的客户端插件,包括数据可视化、执行增删改查操作等。 项目地址:https://github.com/mobz/elasticsearch-head Docker 安装: Elasticsearch 5.x 安装: docker run -p 9100:9100 mobz/elasticsearch-head:5 Elasticsearch 2.x 安装: docker run -p 9100:9100 mobz/elasticsearch-head:2 Elasticsearch 1.x 安装: docker run -p 9100:9100 mobz/elasticsearch-head:1 alpine 镜像 mobz/elasticsearch-head:5-alpine 安装完成后,使用浏览器打开 http://localhost:9100/ Google Chrome 浏览器插件安装:直接在谷歌浏览器插件中心搜索 ElasticSearch Head,搜索到安装好就可以直接使用,简单方便。 elasticsearch-head Dashboard 展示: Dejavu Dejavu 也是一个 Elasticsearch的 Web UI 工具,其 UI界面更符合当下主流的前端页面风格,因此使用起来很方便。 项目地址:https://github.com/appbaseio/dejavu/ Docker 安装: $ docker run -p 1358:1358 -d appbaseio/dejavu open http://localhost:1358/ Dejavu Dashboard 展示: 数据预览页面非常直观,索引/类型/文档 显示得一清二楚 视觉过滤器 image 整理数据,直观地查找信息,隐藏不相关的数据并使一切有意义。对于所有本机数据类型,我们都有。全局搜索栏允许您在数据集中执行文本搜索。 此外,任何过滤的视图都可以导出为JSON或CSV文件。 现代UI元素 im

联系我们

联系电话

4000-640-466

联系邮箱

service@f-li.cn

办公地址

上海黄浦区外滩源1号

谢谢,您的信息已成功发送。
请填写信息。