OpenStack提交代码的review流程

　　本文整理向openstack社区提交代码的基本流程，以及社区一些介绍资料。如有转载，请注明出处！

　　先放张图说明一下OpenStack的code review的大体流程：

　　对OpenStack提交代码更改的流程主要如下：

  • 配置Git与Gerrit环境
  • 克隆目标项目的代码并在新branch上进行更改
  • commit到本地的repo后推送给远端Gerrit，然后由reviewer给出意见
  • 根据reviewer的修改意见不断更新patch

　　其中OpenStack使用Gerrit作为代码review系统，使用Jenkins系统对代码进行自动测试，使用tox工具可以在本地进行相同的代码测试。

基本前提

  1. 创建一个Launchpad账号（Gerrit使用Launchpad进行SSO）
  2. 登录Gerrit，完成基本配置
  3. 加入OpenStack基金会
  4. 签署Contributor License Agreement
  5. 安装 Git 和 git review

　　本文所有操作在Ubuntu Server 14.04 LTS上进行

配置Git

　　首先配置Git命令行工具，便于以后的操作

$ git config --global user.name ‘YourName‘
$ git config --global user.email [email protected]
$ git config --global gitreview.username YourName

　　如果需要查看Git的配置：

$ gir config --list

安装配置Git-Review

　　1. git-review工具是一组Git子命令，主要用于和OpenStack的代码review系统Gerrit交互，git-review和Gerrit的交互是一组Git命令，在每个git review命令后添加-v选项可以打印所有运行的Git命令。

$ sudo apt-get install git-review

　　2. 在你要提交代码的机器上生成一个SSH key：

 $ ssh-keygen –t rsa 

　　如果创建RSA密钥时设置了口令，该口令需要妥善保管，因为以后每一次提交都需要验证该口令。

　　3. 查看公钥部分并将其复制到git-review：

$ less ~/.ssh/id_rsa.pub

　　将公钥部分的内容添加到git-review即可。

在本地克隆代码库

  1. 克隆源码
$ git clone https://github.com/openstack/YourTargetProjectName.git
  1. 进入到克隆后的目录
$ cd YourTargetProjectName
  1. 建立git review 环境
$ git review -s

This repository is now set up for use with git-review. You can set the default username for future repositories with:
git config --global --add gitreview.username yourgerritusername
  1. 可以在Git中设置Gerrit/Launchpad的用户名，
$ git config --global --add gitreview.username YourName
  1. check out 到master分支，更新远端并将其pull到本地的master分支
$ git checkout master; git remote update; git pull origin master

　　6. 在Launchpad上report 一个新的bug， 或者找一个尚未被解决的bug然后将它assign给自己，将bug的状态改为In progress， OpenStack使用Launchpad记录Blueprints和报告bugs。

　　7. 想要fix某个bug，就必须新建一个分支，然后在这个分支里对源代码进行修改，例如：

$ git checkout -b fix-bug-#123456
  1. 上述命令创建并切换到新分支“fix-bug-#123456”，接下来所有的本地工作在这个分支里进行，直到所有fixation都完成后再commit，
$ git commit -a

　　提交时会要求输入commit message，commit message可以有下面的字段：

　　Implements: blueprint BLUEPRINT

　　Closes-Bug: #123456

　　Partial-Bug: #123456

　　Related-Bug: #123456

　　通过这些字段来标识自己工作相关的bug或者blueprint，一旦注明，CI系统会自动将你的commit和相同ID的bug对应起来。

  1. 上面的命令提交到本地repo后接下来就是push到Gerrit了。
$ git review -v

　　Gerrit是OpenStack远端Git仓库的一道大门，所有的submission都要在这里经过review后才能被merge到master分支中，因此之前的工作一定不能在master分支进行，这样会产生一个merge commit，Gerrit默认是不接受merge commit的。

　　如果提交成功，Gerrit将返回一个显示你此次提交内容的URL，打开它就可以查看commit以及reviewer的评价了：http://review.openstack.org/nnnnnn

如果需要修改commit怎么办？

　　此时需要到http://review.openstack.org上查找自己的patch记录，然后记下这一个patch的review number，就是review.openstack.org对应patch页面的后几位数字：https://review.openstack.org/#/c/nnnnnn/

$ cd ourTargetProjectName    #切换到项目源码目录
$ git review -d nnnnnn        #把patch给check out，然后就可以编辑了

　　接着根据reviewer们的意见重新编辑patch，然后提交

$ git commit -a --amend    #在本地commit
$ git review

　　对上一次的commit进行了修改，或者commit message没有写标准，都可以重新提交commit，但是一定要切换到自己上次提交commit的分支执行上面的命令。如果希望查看完整的git命令流，可以在git review命令后添加 -v选项。

2015-04-01 12:24:50.927128 Running: git log --color=never --oneline HEAD^1..HEAD
2015-04-01 12:24:50.930189 Running: git remote
2015-04-01 12:24:50.932609 Running: git branch -a --color=never
2015-04-01 12:24:50.935309 Running: git rev-parse --show-toplevel --git-dir
2015-04-01 12:24:50.937601 Running: git remote update gerrit
Fetching gerrit
2015-04-01 12:25:04.406800 Running: git rebase -i remotes/gerrit/master
2015-04-01 12:25:04.507110 Running: git reset --hard ORIG_HEAD
2015-04-01 12:25:04.514952 Running: git config --get color.ui
2015-04-01 12:25:04.517383 Running: git log --color=always --decorate --oneline HEAD --not remotes/gerrit/master --
2015-04-01 12:25:04.523654 Running: git branch --color=never
2015-04-01 12:25:04.526527 Running: git log HEAD^1..HEAD
Using local branch name "fix-bug-123456" for the topic of the change submitted
2015-04-01 12:25:04.530764 Running: git push gerrit HEAD:refs/publish/master/fix-bug-123456
remote: Processing changes: updated: 1, refs: 1, done
remote: (W) 81a1233: commit subject >65 characters; use shorter first paragraph
remote: (W) 81a1233: no files changed, message updated
To ssh://[email protected]:29418/openstack/TargetProject.git
 * [new branch]      HEAD -> refs/publish/master/fix-bug-123456
2015-04-01 12:25:11.126958 Running: git rev-parse --show-toplevel --git-dir

一些Troubleshoot，

　　如果配置Git或Gerrit的过程中遇到了问题，https://wiki.openstack.org/wiki/Documentation/HowTo/FirstTimers的最后提供了常见问题的troubleshoot，可以参考。

OpenStack的Commit Message风格，

　　这里对于每一次提交commit时commit message的风格有一定的介绍：https://wiki.openstack.org/wiki/GitCommitMessages

OpenStack的bug分流，

　　这里有OpenStack对不同程度的bug进行分流的介绍：https://wiki.openstack.org/wiki/BugTriage

OpenStack的bug分类，

　　OpneStack根据状态、重要程度等指标对Bug进行分类：https://wiki.openstack.org/wiki/Bugs

OpenStack的blueprints，

　　WIKI介绍：https://wiki.openstack.org/wiki/Blueprints

　　Launchpad上的OpenStack项目首页：https://blueprints.launchpad.net/openstack

OpenStack所有项目的Spec，

　　specifications记录了每个项目的设计规范，这里是所有项目的Specs：http://specs.openstack.org/

OpenStack的发行周期，

　　这里是关于发行周期的一些介绍，https://wiki.openstack.org/wiki/ReleaseCycle

　　所有OpenStack项目的分支tar包：http://tarballs.openstack.org/

OpenStack代码分支模型，

　　这里是代码分支模型的介绍，https://wiki.openstack.org/wiki/Branch_Model

时间： 2024-10-08 17:41:49

OpenStack提交代码的review流程的相关文章

如何向OpenStack提交代码（详细步骤）

1. 创建一个 Launchpad(https://launchpad.net/openstack  )账号,加入OpenStack社区. 2. 在(https://www.openstack.org/profile  )上注册账号(这里的账号与1.中的账号,邮箱应该一致),并成为Foundation Member(否则后面提交会出现问题). 3. 进入(https://review.openstack.org  ),登陆. 4. 进入(https://review.openstack.org/

Github提交代码的流程

1.生成密钥公钥文件 ssh #检查是否安装SSH ssh -keygen -t rsa #指定RSA算法生成密钥,紧接着按连续3个enter键(不需要输入密码),就会生成id_rsa和id_rsa.pub文件,一个密钥,一个公钥 MeWifi:demo cjy$ ssh usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file]

在VS上的Git提交代码的流程步骤

1 点击 团队资源管理器 2 点击 更改 3 (1)输入提交信息(在黄色底纹的文本框区域 Finish TASK 4057.对.....) (2)在相关工作项下 输入任务分配时的ID(点击+号) (3)在更改数下 确认自己更改的项目.更改的类等(右键选中某个cs文件,点击暂存) 4 点击黄色底纹的文本框区域 下方的**提交按钮(提交临时数据按钮) //5 **提交完之后,上方浮动显示一条黄色文字,点击内部的“同步”按钮 (已本地创建 提交 a5bab915.同步以与服务器共享你的更改) 6 最后

企业中git管理代码的基本流程

现在,基于git的诸多优点,现在许多公司都选择使用git管理自己的代码,基本的流程如下: 1. 创建自己的分支,并进行开发 git checkout -b mybranch; //创建并切换到分支mybranch上 2. 开发完成后,从本地放到暂存区 git add file1 [file2] [...] ;//将新增或修改后的文件file1,file2...放到暂存区 3. 提交到本次仓库 git commit -m [message] -n; //加上-n表示忽略注释中的语法错误 4. 切换

Code Review流程工具Jupiter介绍

引言 Code Review的作用和意义已在很多技术团队内达成共识,可是很多时候并未被有效执行,甚至被认为是一项费时费力的工作.借助一些工具可以更容易,更有效率地来进行Code Review,本文介绍的Jupiter即是其中之一. Jupiter概述 Jupiter是一款开源的Eclipse插件,以XML形式存储review数据,通过SVN/CVS将review结果在团队内共享.一个很方 便的功 能是其建立了review问题跟具体源代码的对应关系(通过点击review问题列表中的问题可以跳转到对

GIT入门笔记（20）- git 开发提交代码过程梳理

git开发提交流程新项目开发,可以直接往master上提交老项目维护,可以在分支上修改提交,多次add和commit之后,也可以用pull合并主干和本地master,解决冲突后再push 1.检出代码 git clone http://gitserver/kubernetes/api-gateway-controller.git git clone http://gitserver/kubernetes/api-gateway-engine.git 引入为eclipse工程,修改代码 2.提交代

第一次提交代码到github时经常遇到的问题

最近两年在OpenStack方面做了一些工作,写了一些实验性的plugin. 本着Open Source的共享精神,想尝试提交到github,以便他人能下载使用. 当你注册完github帐号之后,点击有上面的“+”图标创建一个source code的repository. 下面以我的monasca plugin for heat 为例. 执行一下几步可以第一次提交你的代码: -------------------------------------------------------------

openstack之虚拟机的创建流程

这篇博文静静的呆在草稿箱大半年了,如果不是因为某些原因被问到,以及因为忽略它而导致的损失,否则我也不知道什么时候会将它完成.感谢这段时间经历的挫折,让我知道不足,希望你能给我更大的决心! 本文试图详细地描述openstack创建虚拟机的完整过程,从用户发起请求到虚拟机成功运行,包括客户端请求的发出.keystone身份验证.nova-api接收请求.nova-scheduler调度.nova-computer创建.nova-network分配网络.对于每一个模块在创建虚拟机的过程中所负责的功能和

mirantis fuel puppet执行顺序 和 对整个项目代码的执行流程理解

stage执行顺序 stage {'zero': } -> stage {'first': } -> stage {'openstack-custom-repo': } -> stage {'netconfig': } -> stage {'corosync_setup': } -> stage {'openstack-firewall': } -> Stage['main'] 1.class {'begin_deployment': stage => 'zero