ci

说明：Jenkins折腾了好几个月了，打算写个系列记录下。有时间会尽量更新的。 第一章 Jenkins是什么？ Jenkins 是一个可扩展的持续集成引擎。 主要用于： l 持续、自动地构建/测试软件项目。 l 监控一些定时执行的任务。 Jenkins拥有的特性包括： l 易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。 l 易于配置-所有配置都是通过其提供的web界面实现。 l 集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。 l 生成JUnit/TestNG测试报告。 l 分布式构建支持Jenkins能够让多台计算机一起构建/测试。 l 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。 l 插件支持:支持扩展插件，你可以开发适合自己团队使用的工具。 1 Jenkins的由来 目前持续集成(CI)已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见做法。它是一种实践，旨在缓和和稳固软件的构建过程。并且能够帮助您的开发团队应对如下挑战： l 软件构建自动化 ：配置完成后，CI系统会依照预先制定的时间表，或者针对某一特定事件，对目标软件进行构建。 l 构建可持续的自动化检查 ：CI系统能持续地获取新增或修改后签入的源代码，也就是说

文章目录 软件开发工作流程 持续集成（CI） 持续交付 持续部署（CD） Jenkins介绍 Jenkins概念 Jenkins特性 软件开发工作流程 互联网软件的开发和发布，已经形成了一套标准流程，把开发工作流程分为以下几个阶段： 编码 → 构建 → 集成 → 测试 → 交付 → 部署 持续集成（CI） 上面整个流程中最重要的组成部分就是持续集成（Continuous integration，简称CI）。 持续集成指的是，频繁地（一天多次）将代码集成到主干。将软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。 它的好处主要有两个： 1. 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易； 2. 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成并不能消除Bug，而是让它们非常容易发现和改正。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。Jenkins 是一个开源软件项目，旨在提供一个开放易用的软件平台，使持续集成变成可能。 持续交付 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过

CI框架是使用php写的一套框架，读起来相对比较简单。 正常来说，CI有两个重要的文件夹，第一个是application，这个用户开发的代码存放地址，另外一个是system这个是真正CI源码的位置。 CI的根目录下面的index.php 这个文件里面配置了需要关心的各个配置。 第一个是 ENVIRONMENT 这个环境变量，这个变量在后面的加载类的时候，指定到底调用哪个累文件，标准情况下一个是development开发，一个是production。 define('ENVIRONMENT', isset($_SERVER['CI_ENV']) ? $_SERVER['CI_ENV'] : 'development'); 第二个 是系统$system_path，用来表示用的CI源码在哪里。 第三个 是$application_floder 用来定义自己的项目代码目录 第四个是 BASEPATH这个其实就是$system_path define('BASEPATH', $system_path); 第五个 是APPPATH 这个是$application_floder加上'/' 当然这里根据$application_floder是否是目录，还进行一些逻辑上的容错处理。 最后也是最重要的引入CI框架的初始化文件 require_once BASEPATH.'core

对CI框架中几个文件libraries,helpers,hooks夹说明 来源：未知 时间：2014-10-20 11:37 阅读数：117 作者：xbdadmin [导读] 1.library文件夹 如果你想扩展CI的功能，那么就把你的类库放在这，注意，这个文件夹是有class组成的，可以看看如果 加载library注意事项 ！ 2.helper文件夹 如果你需要使用一些函数来帮你... 1.library文件夹 如果你想扩展CI的功能，那么就把你的类库放在这，注意，这个文件夹是有class组成的，可以看看如果 加载library注意事项 ！ 2.helper文件夹 如果你需要使用一些函数来帮你完成一些小功能，那么就把它放着，这里都是过程式的代码而不是类，一般helper是用于view的， 使用方法如下： $this->load->helper(' filename ') filename 是辅助函数对应的文件名，不包括 _helper.php 扩展名。文件名应该保存为：filename_helper.php，放在helper文件夹下！ 3.hooks文件夹 存放你创建的钩子。钩子是 用来装载其它文件的控制方法,不能被控制器等调用，是系统自动调用的。当 CodeIgniter 运行后，它会产生出一个特殊的进程。 当然，您可以自定义一些动作来替代程序运行过程中的某些阶段。例如

这个本来是很基础的东西，基本上用过CI的人都知道这些，原本是不消说的~但是因为毕业论文是关于CodeIgniter的，所以我必须把大大小小的东西都写出来做成记录~ CodeInigter,一个轻量，功能全面的PHP框架，使开发者可以轻易的使用MVC的结构来开发web应用。 下载一份CI的代码（最新的为 2012.10.08 更新的 2.1.3 ），我们可以看到根目录下只有五个文件/文件夹，其中 user_guide 文件夹里为说明文档， license.txt 为许可协议，去掉 user_guide 的 CodeIgniter 只有1M多一点，从这点就可以看出这是一个很轻量的框架。 甚于的文件只有三部分， index.php 、 systerm 文件夹和 application 文件夹。我们可以分开分析。 index.php index.php是CI的入口文件件，换句话说，用CI搭建的框架，我们发送的请求都是请求的这个文件，后面跟的 controller 和 method 都是跟在URL后面的参数。 比如 http://localhost/index.php?/admin/main ，问号以后实际上都是参数了。 为了方便用户浏览，我们在 .htaccess 和 http.conf 里开启了隐藏 /index.php? ，把URL写成 http://localhost/admin

CI目录结构 CI主要组成部分为，application（应用文件夹）、system（系统文件夹）和index.php入口文件。 应用文件夹中主要是存放控制器、模型和视图等，系统文件夹中主要是存放组成CI的核心文件的，index.php入口文件是一个单一入口文件，所谓单一文 件是指在一个网站(应用程序)中,所有的请求都是指向的这么一个文件，由它负责接收并处理URL中的控制器和方法。换句话说, 它调用一个 '控制器', 然后返回一个'视图'。 application ： cache 第一次安装时为空，如果你打开缓存设置，这个目录存放缓存数据 config 存放配置文件，包含网站的基本配置信息 controllers 存放你项目的控制器目录 core 该目录可以扩展系统的核心文件 errors 包含出错信息页，你不必修改这个目录 hooks 首次安装时为空，用来存放你创建的钩子。钩子是 用来装载其它文件的控制方法 helpers 辅助函数，你可以对系统的辅助函数进行扩展 language 存放你本国语言的文件目录 libraries 类库，你可以创建自己的类库 logs 如果你设置打开了系统的错误日志，日志文件就默认保存在这个目录 models 存放你项目的模型目录 views 存放视图的模板目录 system ： core 存放系统核心文件 database

CI目录结构 CI主要组成部分为，application（应用文件夹）、system（系统文件夹）和index.php入口文件。 应用文件夹中主要是存放控制器、模型和视图等，系统文件夹中主要是存放组成CI的核心文件的，index.php入口文件是一个单一入口文件，所谓单一文件是指在一个网站(应用程序)中,所有的请求都是指向的这么一个文件，由它负责接收并处理URL中的控制器和方法。换句话说, 它调用一个 '控制器', 然后返回一个'视图'。 application ： cache 第一次安装时为空，如果你打开缓存设置，这个目录存放缓存数据 config 存放配置文件，包含网站的基本配置信息 controllers 存放你项目的控制器目录 core 该目录可以扩展系统的核心文件 errors 包含出错信息页，你不必修改这个目录 hooks 首次安装时为空，用来存放你创建的钩子。钩子是 用来装载其它文件的控制方法 helpers 辅助函数，你可以对系统的辅助函数进行扩展 language 存放你本国语言的文件目录 libraries 类库，你可以创建自己的类库 logs 如果你设置打开了系统的错误日志，日志文件就默认保存在这个目录 models 存放你项目的模型目录 views 存放视图的模板目录 system ： core 存放系统核心文件 database

通过 .gitlab-ci.yml配置任务 此文档用于描述.gitlab-ci.yml语法，.gitlab-ci.yml文件被用来管理项目的runner 任务。 如果想要快速的了解GitLab CI ，可查看 快速引导 。 .gitlab-ci.yml 从7.12版本开始，GitLab CI使用 YAML 文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，它定义该项目如何构建。 开始构建之前YAML文件定义了一系列带有约束说明的任务。这些任务都是以任务名开始并且至少要包含 script 部分： job1: script: "execute-script-for-job1" job2: script: "execute-script-for-job2" 上面这个例子就是一个最简单且带有两个独立任务的CI配置，每个任务分别执行不同的命令。 script 可以直接执行系统命令(例如：./configure;make;make install)或者是直接执行脚本(test.sh)。 任务是由 Runners 接管并且由服务器中runner执行。更重要的是，每一个任务的执行过程都是独立运行的。 用下面这个例子来说明YAML语法还有更多复杂的任务： image: ruby:2.1 services: - postgres before_script: -

ZJOI2019Day2的温暖题，然后考场上只会大常数的 \(O(n\log^3 n)\) ，就懒得写拿了60pts走人 首先我们简化题意，容易发现每个点能到达的点形成了一个 联通块 ，我们只需要统计出这个联通块的大小即可 再进一步，我们发现如果把每条经过 \(x\) 的路径 \((u,v)\) 上的两个端点取出，并且维护它们之间的 最小生成树 ，这棵生成树的大小就是最后的答案（可以画图或是感性理解） 接下来就考虑怎么维护每个点出去的生成树大小，首先我们强制选择 \(1\) 号点，然后用类似于 建虚树 的方法，每次加入一个新的点就通过 LCA 来计算距离，从而推出生成树的大小 所以大致思路也有了，我们需要一个能维护区间的支持插入删除的数据结构，那么很容易想到用 线段树 了 那么怎么维护经过一个点的所有路径呢，其实很套路，因为这里线段树上的基本信息就是一个点的存在与否，因此可以 树上差分 具体的，对于一条路径 \((u,v)\) ，我们在以 \(1\) 为根的树上将 \(u,v\) 两点打上标记，然后在 \(\operatorname{LCA}(u,v),father_{\operatorname{LCA}(u,v}\) 上删除即可 离线之后就是套路的 线段树合并了 ，然后中间转移有一个求 \(\operatorname{LCA}\) 的过程，用 欧拉序+RMQ 即可做到 \(O(n

　　数据来自于一个不完全清楚的过程。以投掷硬币为例，严格意义上讲，我们无法预测任意一次投硬币的结果是正面还是反面，只能谈论正面或反面出现的概率。在投掷过程中有大量会影响结果的不可观测的变量，比如投掷的姿势、力度、方向，甚至风速和地面的材质都会影响结果。也许这些变量实际上是可以观测的，但我们对这些变量对结果的影响缺乏必要的认知，所以退而求其次，把投掷硬币作为一个随机过程来建模，并用概率理论对其进行分析。 　　 　　概率有时也被解释为频率或可信度，但是在日常生活中，人们讨论的概率经常包含着主观的因素，并不总是能等同于频率或可信度。比如有人分析中国足球队打进下次世界杯的概率是10%，并不是说出现的频率是10%，因为下次比赛还没有开始。我们实际上是说这个结果出现的可能性，由于是主观的，因此不同的人将给出不同的概率。 　　在数学上，概率研究的是随机现象背后的客观规律。我们对随机没有兴趣，感兴趣的是通过大量随机试验总结出的数学模型。当某个试验可以在完全相同的条件下不断重复时，对于任意事件E（试验的可能结果的集合，事件是集合，不是动作），结果在出现在E中的次数占比趋近于某个常量，这个常数极限是事件E的概率，用P(E)表示。 　　我们需要对现实世界建模，将现实世界的动作映射为函数，动作结果映射为数。比如把投硬币看作f(z)，z是影响结果的一系列不可观测的变量，x 表示投硬币的结果，x = f(z)