1.旧版本的Jenkins可以使用Dynamic Choice Parameter插件: 使用方法: Jenkins--->dev-h5-server--->配置--->参数化构建过程--->选择Dynamic Choice Parameter插件: Name:   git_branch Choices Script : def gettags = ("git ls-remote -h http://10.0.10.25/h5-server.git").exec

1.环境 本文使用VMWare虚拟机进行实验. 最终实现目标,在Jenkins服务器上新建构建任务,从Git服务器上拉取master HEAD(不编译,仅演示),部署到"目标服务器",再执行一个脚本. Jenkins服务器 2核CPU,4GB内存,20GB硬盘,IP:192.168.118.145(要求能上网,装插件) CentOS 7.2最小安装(CentOS-7-x86_64-Minimal-1511.iso) Git远程库服务器 IP: 192.168.118.148 已经存在一

使用git管理代码时往往会有多分支开发,这时部署通过修改配置不试用.可以通过参数化构建. 1.通过字符参数方式 新建一个maven项目,选择参数化构建过程-字符参数,如下: 源码管理中配置如下: 其它配置正常. 配置完后发现立即构建变成了Build with Parameters 点击构建如下,会让你输入变量名,这里配置了默认值: 这时候点击Build,就可以了. 2. 通过Git Parameter方式 这种方式需要安装插件Git Parameter 新建maven项目,选择参数化构建过程-G

1,安装zsh sudo apt-get install zsh 2,克隆项目 git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh 3,创建新的.zshrc文件 cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc 4,备份~/.zshrc文件(为以后做打算) cp ~/.zshrc ~/.zshrc.orig 5,改变系统默认的bash环境 chsh -s /

一,创建jenkins项目 new item ->freestyle project, 自定义一个项目名称 二,配置项目 1,Source Code Management 选择 git,输入git项目地址 2,添加一个账户:即将登录git的账号添加到jenkins,添加完成后选择这个账号 3,Branches to build, 填写需要被构建的分支名称,这里通常填 */develop 4,Post-build Actions 选择 "send build artifacts over S

Jenkins 配合 GitLab 实现分支的自动合并.自动创建 Tag 背景 GitFlow工作流简介 Gitflow工作流定义了一个围绕项目发布的严格分支模型,它会相对复杂一点,但提供了用于一个健壮的用于管理大型项目的框架,非常适合用来管理大型项目的发布和维护. 贯穿整个开发周期,master和develop分支是一直存在的,master分支可以被视为稳定的分支, 而develop分支是相对稳定的分支,特性开发会在feature分支上进行,发布会在release分支上进行,而bug修复则会在

基于Python实现自动拉取Git分支源码自动解析并执行SQL语句 by:授客 QQ:1033553122 1．代码用途 开发过程中,研发人员会提交SQL更新脚本到Git源码库,然后测试负责去拉取这些SQL脚本,并手动在测试环境或其它环境的数据库中执行这些脚本,很麻烦,本代码的用途就是为了替代手工执行的操作 2．测试环境 Win7 64位 Python 3.3.2 git-credential-winstore.exe 下载地址: https://pan.baidu.com/s/1hsehGjU

先下载插件: Git Paramater 参照: jenkins-参数化构建(三)插件:Git Parameter https://www.cnblogs.com/zhaojingyu/p/9862443.html jenkins实现手动选择分支构建项目 https://blog.51cto.com/9025736/2061667 期望效果: 需求: 由于我们的程序会有很多分支,测试或者发版会根据不同的分支来构建项目实践: 实现在构建项目的时候弹出弹窗提醒我们来构建那个分支的项目,来构建不同环境

为了便于项目中对发布的版本进行回滚,所以我们每次发布完成以后自动创建git tag. 1,创建一个Jenkins任务,命名成为push_tag_demo: 2,配置<源码管理>,这里配置比较特殊的地方需要仓库的名字,后面创建tag的时候需要使用: 3,在<构建后操作>操作中选择"Git Publisher",来配置发布后执行的任务. 注意: 配置Git Publisher 时,需要我们勾选"Push Only If Build Succeeds&quo

为了便于项目中对发布的版本进行回滚,所以我们每次发布完成以后自动创建git tag. 1,创建一个Jenkins任务,命名成为push_tag_demo: 2,配置<源码管理>,这里配置比较特殊的地方需要仓库的名字,后面创建tag的时候需要使用: 3,在<构建后操作>操作中选择"Git Publisher",来配置发布后执行的任务. 注意: 配置Git Publisher 时,需要我们勾选"Push Only If Build Succeeds&quo

一.背景 因为代码都迁移到了Gitlab,所以Jenkins编译的时候我们都需要将之前的SVN信息换成现在的Git信息.最近编译一个Lib库的时候,因为团队规定上传Release版本的AAR到Maven的话,必须需要在Jenkins上编译而且Git Branch 必须是master分支才能够上传到Maven. 因此我们就需要在Gradle脚本中,获取Git Branch ,Git Commit等相关信息.但是在获取Git Branch的时候出现了问题,在本地Android Studio编译的时候

背景 有个私有仓储,地址为https://your.repo.com/pypi/ 代码存储在gitlab, 地址为https://gitlab.company.com/software.git CI为jenkins 常规解决手法 jenkins有一个特定的节点,节点里面已经配置好了%HOMEPATH%/.pypirc [distutils] index-servers = deploy [deploy] repository=https://your.repo.com/pypi/ usernam

写在前面 初步接触持续集成自动化过程,本篇主要介绍基于Jenkins实现持续集成的方式,通过案例介绍线上自动编译及部署的配置过程 持续集成 持续集成是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误. Jenkins Jenkins是基于Java开发的一种持续集成工具,用于监控持续重复的工作,功能包括: 1.持续的软件版本发布/测试项目. 2.

在这篇文章中,我将推广一下大约一年前我介绍过的一些项目(公私皆有)中使用的开发模型,它们的结果都非常成功.有段时间我非常想写出来分享一下,但是我至今才抽出时间来.我不会言及任何项目细节,仅讨论分支策略和发布管理. 为何使用 git? 关于 Git 和集中式源码版本控制系统的优缺点对比讨论, 见 此 web.这里有很多精彩激烈的论战.作为一名开发者,现在我更偏好使用 Git .Git 真的改变了开发者关于合并和分支的认知.我来自传统的 CVS/Subversion 世界,合并/分支是件恐怖的事情

翻译自:https://nvie.com/posts/a-successful-git-branching-model/ 在这篇文章中,主要介绍 Git 分支模型.不会谈论任何项目的细节,只讨论分支策略和发布管理. Git分布式和集中式理解 我们配置了中央存储库可以很完美的配合该分支模型工作.这里需要注意下,这个仓库只是被认为 是中央仓库(因为Git是DVCS(分布式版本管理系统),在技术层面上没有中央仓库).我们将这个中央仓库称为origin,应该所有Git用户都熟悉这个名称. 每个开发人员都

Markdown版本笔记 我的GitHub首页 我的博客 我的微信 我的邮箱 MyAndroidBlogs baiqiantao baiqiantao bqt20094 baiqiantao@sina.com 自动化打包 Jenkins 持续集成 Git Gradle MD 目录 目录环境要求Jenkins 环境配置Jenkins 安装全局工具配置Android SDK 路径配置邮件配置创建并配置打包任务参数化构建工作空间配置源码管理构建触发器构建上传apk到蒲公英构建后操作打包 环境要求 JD

#新建代码库git init # 在当前目录新建一个Git代码库git init [project-name] # 新建一个目录,将其初始化为Git代码库git clone [url] # 下载一个项目和它的整个代码历史#配置gitgit config [--global] user.name "your name"git config [--global] user.email "your email address"#分支git branch -r # 查看远程

近两个月由于个人处于新环境.新项目的适应阶段,没怎么提笔写些文章.中间有好几个想法想记录下来分享,但受限于没有很好的时间段供自己总结思考(也可以总结为间歇性懒癌和剧癌发作),便啥也没有更新.借这个周末闲适的下午和明媚的阳光,决定把近来项目上的CI/CD(持续集成/持续交付)策略以及git分支模型和以前的项目做一下分析比较,希望对各位有所帮助,也能有所思考,尤其是那些期望搭建项目部署流水线或者想了解git分支模型的开发.运维人员.背景  废话不多说,由于近期做了N次release,所以对自己目前所

ps:本文转载于 : https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html Git 是目前最流行的源代码管理工具.大量的软件项目由 GitHub.Bitbucket 和 GitLab 这样的云服务平台或是私有的 Git 仓库来管理.在使用 Git 时通常会遇到的一个问题是采用何种分支管理实践,即如何管理仓库中作用不同的各类分支.和软件开发中的其他实践一样,Git 分支管理并没有普遍适用的最佳做法,而只有对每个团队

当时也是花费了不少时间来配置Jenkins自动打包的问题,觉得还是需要记录一下. 1.安装Jenkins,这个很简单,不需要多说. 2.下载Git Plugin,Gradle Plugin,Android Emulator Plugin(这个可以配置SDK路径,觉得这个插件挺好), Email Extension Plugin 邮件提醒插件,自带的邮件提醒插件确实太弱. 3.配置,SDK路径,JDK路径,Git路径,Gradle路径. 配置git: git config –global user