本章包含有关构建和发布HBase代码和文档的信息和指南。熟悉这些指南将有助于HBase提交者更轻松地使用您的贡献。
只有当人们贡献时,Apache HBase才会变得更好!如果您希望为Apache HBase做出贡献,请在JIRA中查找标有'beginner'%20AND%20status%20in%20标签的[问题(开放%2C%20%22In%20Progress%22%2C %20Reopened))。这些是HBase贡献者认为值得的问题,但不是当下的优先事项,也是延长HBase内部的好方法。请参阅](https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)[对于新贡献者的斜坡问题,使用什么标签?](http://search-hadoop.com/m/DHED43re96) 来自dev邮件列表的背景信息。
在开始向HBase提交代码之前,请参考开发。
由于Apache HBase是Apache Software Foundation项目,请参阅 asf 以获取有关ASF如何运行的更多信息。
注册dev-list和用户列表。请参阅邮件列表页面。鼓励提出问题 - 并帮助回答其他人的问题!两个列表都有不同程度的经验,因此鼓励耐心和礼貌(请留待主题。)
Apache HBase项目有自己的链接: Slack Channel ,用于实时问题和讨论。邮寄 dev@hbase.apache.org 请求邀请。
(注意:我们的IRC频道似乎已被弃用,以支持上述Slack频道)
对于实时问题和讨论,请使用 FreeNode IRC网络上的#hbase IRC频道。 FreeNode提供基于Web的客户端,但大多数人更喜欢本机客户端,并且每个操作系统都有几个客户端。
检查 Jira 中的现有问题。如果是新功能请求,增强功能或错误,请提交故障单。
我们在JIRA中跟踪多种类型的工作:
-
错误:HBase本身就有问题。
-
测试:需要进行测试,或者测试被破坏。
-
新功能:您对新功能有所了解。通常最好首先将它们放在邮件列表上,然后编写一个设计规范,添加到功能请求JIRA中。
-
改进:存在一个功能,但可以进行调整或扩充。通常最好先将它们放在邮件列表上并进行讨论,然后总结或链接到讨论,如果其他人似乎对改进感兴趣。
-
希望:这就像一个新功能,但对于某些你可能没有背景来充实自己的东西。
错误和测试具有最高优先级,应该是可操作的。
-
搜索重复项:您的问题可能已被报告过。看一看,意识到其他人可能会以不同的方式描述摘要。
还可以搜索邮件列表,其中可能包含有关您的问题以及如何解决问题的信息。不要为已经在邮件列表中讨论和解决的问题提出问题,除非您强烈反对决议并且愿意帮助解决问题。
-
公开讨论:使用邮件列表讨论您发现的内容,看看是否有遗漏的内容。避免使用反向渠道,以便您从整个项目的经验和专业知识中受益。
-
不要代表他人提交:你可能没有所有的上下文,而且你没有那么多的动机来把它看成是实际遇到这个bug的人。从长远来看,鼓励他人提出自己的问题会更有帮助。指出这些材料并提供第一次或第二次帮助。
-
写一个很好的总结:一个很好的总结包括有关问题的信息,对用户或开发人员的影响以及代码的区域。
-
好:
Address new license dependencies from hadoop3-alpha4 -
改进空间:
Canary is broken如果你写了一个糟糕的标题,别人会为你重写它。这是他们本可以花时间处理这个问题的时候了。
-
-
在描述中给出上下文:在多个部分中考虑这个可能是好的:
-
会发生什么或不会发生什么?
-
它对你有何影响?
-
别人怎么能重现它?
-
什么会“固定”的样子?
您不需要知道所有这些的答案,但尽可能多地提供信息。如果您可以提供技术信息,例如您认为可能导致问题的Git提交SHA,或者您认为问题首次出现在builds.apache.org上的构建失败,请分享该信息。
-
-
填写所有相关字段:这些字段可帮助我们过滤,分类和查找内容。
-
一个错误,一个问题,一个补丁:为了帮助反向移植,不要在多个错误之间拆分问题或修复。
-
如果可以增加价值:即使您不知道如何解决问题,提交问题仍然很好。但是提供尽可能多的信息,愿意分类和回答问题,并愿意测试潜在的修复程序甚至更好!我们希望尽快修复您的问题。
-
如果我们不解决它,请不要沮丧:时间和资源是有限的。在某些情况下,我们可能无法(或可能选择不)修复问题,特别是如果它是边缘情况或有解决方法。即使它没有得到修复,JIRA也是它的公开记录,并且如果它们将来遇到类似的问题,将帮助其他人。
-
要检查您作为初学者可以解决的现有问题,请在JIRA中搜索标有“初学者”%20AND%20status%20in%20标签的[问题(开放%2C%20%22In%20Progress% 22%2C%20Reopened))。](https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)
JIRA优先事项
-
Blocker :仅在问题可能导致数据丢失或群集不稳定时使用。
-
严重:在某些情况下,所描述的问题可能导致数据丢失或群集不稳定。
-
主要:重要但不是悲剧性的问题,例如客户端API的更新,它将添加许多急需的功能或需要修复但不会导致数据丢失的重大错误。
-
次要:有用的增强功能和烦人但不会破坏性的错误。
-
琐碎:有用的增强功能,但通常是化妆品。
示例41. Jira评论中的代码块
Jira中常用的宏是{code}。标签内的所有内容都已预先格式化,如本例所示。
{code}
code snippet
{code}
Apache HBase由多个存储库组成,这些存储库托管在 Apache GitBox 上。这些是以下内容:
-
hbase - 主要的Apache HBase存储库
-
hbase-connectors - Apache Kafka和Apache Spark的连接器
-
hbase-operator-tools - 可操作性和可支持性工具,如 HBase
HBCK2 -
hbase-site - hbase.apache.org网站
-
hbase-thirdparty - 流行的第三方库的重新定位版本
在 dev-support / 文件夹下,您将找到_hbase_eclipse formatter.xml 。我们鼓励您在编辑HBase代码时在eclipse中使用此格式化程序。
转到Preferences→Java→Code Style→Formatter→Import加载xml文件。转到Preferences→Java→Editor→Save Actions,确保选中“格式化源代码”和“格式化编辑行”。
除自动格式化外,请确保遵循 common.patch.feedback 中说明的样式指南。
如果您通过git克隆项目,请下载并安装Git插件(EGit)。附加到您当地的git仓库(通过Git Repositories窗口),您将能够看到文件修订历史记录,生成补丁等。
最简单的方法是使用Eclipse的m2eclipse插件。 Eclipse Indigo或更新版本包括m2eclipse,或者您可以从 http://www.eclipse.org/m2e/ 下载它。它为Eclipse提供了Maven集成,甚至允许您使用Eclipse中的直接Maven命令来编译和测试您的项目。
要导入项目,请单击并选择HBase根目录。 m2eclipse为您找到所有hbase模块。
如果在工作区中安装m2eclipse并导入HBase,请执行以下操作来修复eclipse Build Path。
-
删除_目标_文件夹
-
添加 target / generated-jamon 和 target / generated-sources / java 文件夹。
-
从构建路径中删除 src / main / resources 和 src / test / resources 上的排除项,以避免在控制台中出现错误消息,如下所示:
Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.6:run (default) on project hbase: 'An Ant BuildException has occurred: Replace: source file .../target/classes/hbase-default.xml doesn't exist这也将减少日食构建周期,并使您在开发时更轻松。
您可以从命令行生成Eclipse文件,而不是使用m2eclipse。
-
首先,运行以下命令,构建HBase。你只需要这样做一次。
mvn clean install -DskipTests -
关闭Eclipse,并在终端的本地HBase项目目录中执行以下命令,以生成新的 .project 和 .classpath 文件。
mvn eclipse:eclipse -
重新打开Eclipse并将HBase目录中的 .project 文件导入工作区。
需要为项目设置$M2_REPO类路径变量。这需要设置为您的本地Maven存储库,通常是_〜/ .m2 / repository_
如果未配置此类路径变量,您将在Eclipse中看到如下编译错误:
Description Resource Path Location Type
The project cannot be built until build path errors are resolved hbase Unknown Java Problem
Unbound classpath variable: 'M2_REPO/asm/asm/3.1/asm-3.1.jar' in project 'hbase' hbase Build path Build Path Problem
Unbound classpath variable: 'M2_REPO/com/google/guava/guava/r09/guava-r09.jar' in project 'hbase' hbase Build path Build Path Problem
Unbound classpath variable: 'M2_REPO/com/google/protobuf/protobuf-java/2.3.0/protobuf-java-2.3.0.jar' in project 'hbase' hbase Build path Build Path Problem Unbound classpath variable:
Eclipse目前会抱怨 Bytes.java 。无法关闭这些错误。
Description Resource Path Location Type
Access restriction: The method arrayBaseOffset(Class) from the type Unsafe is not accessible due to restriction on required library /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar Bytes.java /hbase/src/main/java/org/apache/hadoop/hbase/util line 1061 Java Problem
Access restriction: The method arrayIndexScale(Class) from the type Unsafe is not accessible due to restriction on required library /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar Bytes.java /hbase/src/main/java/org/apache/hadoop/hbase/util line 1064 Java Problem
Access restriction: The method getLong(Object, long) from the type Unsafe is not accessible due to restriction on required library /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar Bytes.java /hbase/src/main/java/org/apache/hadoop/hbase/util line 1111 Java Problem
有关在Windows上设置Eclipse for HBase开发的其他信息,请参阅 Michael Morello关于该主题的博客。
您可以设置IntelliJ IDEA以实现与Eclipse类似的功能。跟着这些步骤。
-
选择
-
您无需选择配置文件。确保选中所需的Maven项目,然后单击 Next 。
-
选择JDK的位置。
在IntelliJ IDEA中使用HBase Formatter
使用IntelliJ IDEA的Eclipse Code Formatter插件,您可以导入 eclipse.code.formatting 中描述的HBase代码格式化程序。
为其他IDE镜像 eclipse 设置指令会很有用。如果您想提供帮助,请查看 HBASE-11704 。
HBase是使用Maven编译的。您必须至少使用Maven 3.0.4。要检查Maven版本,请运行命令mvn -version。
JDK版本要求
从HBase 1.0开始,您必须使用Java 7或更高版本从源代码构建。有关受支持的JDK版本的更完整信息,请参见 java 。
所有命令都从本地HBase项目目录执行。
从其java源代码编译HBase的最简单命令是使用package目标,该目标使用编译的文件构建JAR。
mvn package -DskipTests
或者,在编译之前进行清理:
mvn clean package -DskipTests
如上面在 eclipse 中所述设置Eclipse,您也可以在Eclipse中使用Build命令。要创建完整的可安装HBase包需要多做一些工作,请继续阅读。
compile目标不会使用编译的文件创建JAR。
mvn compile
mvn clean compile
要在_〜/ .m2 /_ 目录中安装JAR,请使用install目标。
mvn install
mvn clean install
mvn clean install -DskipTests
请参阅 hbase.unittests 中的 hbase.unittests.cmds 部分
HBase支持针对Apache Hadoop版本构建:2.y和3.y(早期版本工件)。默认情况下,我们针对Hadoop 2.x进行构建。
要针对Hadoop 2.y行中的特定版本进行构建,请设置为-Dhadoop-two.version=2.6.3。
mvn -Dhadoop-two.version=2.6.3 ...
要更改我们构建的Hadoop的主要版本行,请在调用mvn时添加hadoop.profile属性:
mvn -Dhadoop.profile=3.0 ...
以上内容将针对我们在 pom.xml 中作为我们的'3.0'版本的任何显式hadoop 3.y版本构建。测试可能不会全部通过,因此您可能需要通过-DskipTests,除非您倾向于修复失败的测试。
要选择特定的Hadoop 3.y版本,您需要设置hadoop-three.version属性,例如-Dhadoop-three.version=3.0.0。
您可能需要更改驻留在 hbase-protocol 模块或其他模块中的protobuf定义。
在hbase-2.0.0之前,protobuf定义文件遍布所有hbase模块,但现在所有与protobuf相关的文件必须驻留在hbase协议模块中;我们正在尝试包含我们的protobuf使用,以便我们可以自由地更改版本而不会破坏任何下游项目使用protobuf。
protobuf文件位于 hbase-protocol / src / main / protobuf 中。要使更改生效,您需要重新生成类。
mvn package -pl hbase-protocol -am
类似地,内部使用的protobuf定义位于 hbase-protocol-shaded 模块中。
mvn package -pl hbase-protocol-shaded -am
通常,使用本机protoc二进制文件完成protobuf代码生成。在我们的构建中,我们使用maven插件以方便使用;但是,插件可能无法为所有平台检索适当的二进制文件。如果您发现自己处于protoc失败的平台上,则必须从源代码编译protoc,并独立于我们的maven构建运行它。您可以通过在maven参数中指定-Dprotoc.skip来禁用内联代码生成,从而允许您的构建继续进行。
如果您需要手动生成protobuf文件,则不应在后续maven调用中使用
clean,因为这将删除新生成的文件。
有关更多详细信息,请阅读 hbase-protocol / README.txt
您可能需要更改驻留在 hbase-thrift 模块或其他模块中的thrift定义。
thrift文件位于 hbase-thrift / src / main / resources 中。要使更改生效,您需要重新生成类。您可以使用maven profile compile-thrift来执行此操作。
mvn compile -Pcompile-thrift
您可能还想使用以下命令为thrift二进制文件定义thrift.path:
mvn compile -Pcompile-thrift -Dthrift.path=/opt/local/bin/thrift
您可以通过运行以下命令,在不通过发布中描述的发布过程的情况下构建tarball:
mvn -DskipTests clean install && mvn -DskipTests package assembly:single
分发tarball构建在 _hbase-assembly / target / hbase- <version>-bin.tar.gz</version>_中。
您可以通过在maven命令中安装或部署之前使用程序集:单个目标来安装或部署tarball:
mvn -DskipTests package assembly:single install
mvn -DskipTests package assembly:single deploy
如果看到Unable to find resource 'VM_global_library.vm',请忽略它。这不是错误。虽然这是官方丑陋。
建立针对HBase 1。
HBase 1.x需要Java 7才能构建。有关每个HBase版本的Java要求,请参阅 java 。
示例42.示例_〜/ .m2 / settings.xml_ 文件
发布到maven需要您签署要上传的工件。为了让您为自己签名,您可以在 .m2 下的本地存储库中正确配置 settings.xml ,如下所示。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<servers>
<!- To publish a snapshot of some part of Maven -->
<server>
<id>apache.snapshots.https</id>
<username>YOUR_APACHE_ID
</username>
<password>YOUR_APACHE_PASSWORD
</password>
</server>
<!-- To publish a website using Maven -->
<!-- To stage a release of some part of Maven -->
<server>
<id>apache.releases.https</id>
<username>YOUR_APACHE_ID
</username>
<password>YOUR_APACHE_PASSWORD
</password>
</server>
</servers>
<profiles>
<profile>
<id>apache-release</id>
<properties>
<gpg.keyname>YOUR_KEYNAME</gpg.keyname>
<!--Keyname is something like this ... 00A5F21E... do gpg --list-keys to find it-->
<gpg.passphrase>YOUR_KEY_PASSWORD
</gpg.passphrase>
</properties>
</profile>
</profiles>
</settings>
只有提交者可以发布hbase工件。
在你开始之前
确保您的环境设置正确。 Maven和Git是下面使用的主要工具。您需要在本地_〜/ .m2_ maven存储库中正确配置 settings.xml 文件,其中包含apache repos的登录信息(参见示例_〜/ .m2 /settings.xml_ 文件)。您还需要具有已发布的签名密钥。浏览Hadoop 如何发布 wiki页面,了解如何发布。它是下面大多数说明的模型。它通常包含有关特定步骤的更多详细信息,例如,在Apache中将代码签名密钥添加到项目KEYS文件中,或者如何更新JIRA以准备发布。
在制作候选版本之前,请通过部署SNAPSHOT进行练习。检查以确保最近的版本已经从您将要发布的分支传递到该分支。您还应该在加载的集群上尝试最近的分支提示,可能是通过运行hbase-it集成测试套件几个小时来“烧入”近候选位。
为Maven指定堆空间
您可能会遇到OutOfMemoryErrors构建,特别是构建站点和文档。通过设置
MAVEN_OPTS变量为Maven堆起来。您可以将变量作为Maven命令的前缀,如下例所示:MAVEN_OPTS="-Xmx4g -XX:MaxPermSize=256m" mvn package您也可以在shell中的环境变量或别名中设置它。
脚本_dev-support / make rc.sh 自动执行以下许多步骤。它将检出标签,清理结帐,构建src和bin tarball,并将构建的jar部署到repository.apache.org。它没有对发布的 CHANGES.txt 进行修改,检查生成的工件以确保它们“良好” - 例如提取生成的tarball,验证它们是否正确,然后启动HBase并检查一切是否正常运行 - 或者将tarball签名并推送到 people.apache.org 。看一看。根据需要修改/改进。
程序:发布程序
-
更新 CHANGES.txt 文件和POM文件。
使用自上次发布以来的更改更新 CHANGES.txt 。确保JIRA的URL指向正确的位置,该位置列出了此版本的修复程序。适当调整所有POM文件中的版本。如果要创建候选发布版,则必须从所有pom.xml文件中的所有版本中删除
-SNAPSHOT标签。如果您正在运行此receipe以发布快照,则必须在hbase版本上保留-SNAPSHOT后缀。 版本Maven插件可以在这里使用。要在hbase多模块项目的所有poms中设置版本,请使用如下命令:$ mvn clean org.codehaus.mojo:versions-maven-plugin:2.5:set -DnewVersion=2.1.0-SNAPSHOT确保poms中的所有版本都已更改!检查 CHANGES.txt 并更改任何maven版本。
-
更新文档。
更新 src / main / asciidoc 下的文档。这通常涉及从主分支复制最新版本并进行版本特定调整以适应此候选版本。
-
清洁结帐目录
$ mvn clean $ git clean -f -x -d -
运行Apache-Rat Check许可证很好
$ mvn apache-rat如果上述操作失败,请检查鼠标日志。
$ grep 'Rat check' patchprocess/mvn_apache_rat.log -
创建发布标记。假设您已经运行了基本测试,鼠标检查,通过并且一切看起来都很好,现在是标记候选发布者的时间(如果您需要重做,则总是删除标记)。要标记,请在适合您的构建的版本中进行替换。所有标签都应该是签名标签;即通过 -s 选项(参见签署您的工作,了解如何设置您的git环境进行签名)。
$ git tag -s 2.0.0-alpha4-RC0 -m "Tagging the 2.0.0-alpha4 first Releae Candidate (Candidates start at zero)"
或者,如果您要发布,标签应该有一个 rel / 前缀,以确保它们保存在Apache repo中,如下所示:
+$ git tag -s rel/2.0.0-alpha4 -m "Tagging the 2.0.0-alpha4 Release"
推送(特定)标签(仅限)以便其他人可以访问。
$ git push origin 2.0.0-alpha4-RC0
-
有关如何删除标签的信息,请参阅如何删除标签。涵盖删除尚未推送到远程Apache repo的标签以及删除推送到Apache的标签。
-
构建源代码tarball。
现在,构建源代码tarball。让我们假设我们正在为 /tmp/hbase-2.0.0-alpha4-RC0/ 标记 2.0.0-alpha4-RC0 构建源码tarball(此步骤要求刚刚完成了上面描述的mvn和git clean步骤)。
$ git archive --format=tar.gz --output="/tmp/hbase-2.0.0-alpha4-RC0/hbase-2.0.0-alpha4-src.tar.gz" --prefix="hbase-2.0.0-alpha4/" $git_tag
上面我们将hbase-2.0.0-alpha4-src.tar.gz tarball生成到 /tmp/hbase-2.0.0-alpha4-RC0 构建输出目录中(我们不想要 ] RC0 在名称或前缀中。这些位当前是候选版本,但如果VOTE通过,它们将成为释放,因此我们不会使用 RCX 来污染工件名称。
- 构建二进制tarball。接下来,构建二进制tarball。在构建时添加
-Prelease配置文件。它运行许可证apache-rat检查以及其他有助于确保所有内容都有益的规则。分两步完成。
首先安装到本地存储库
$ mvn clean install -DskipTests -Prelease
接下来,生成文档并组装tarball。请注意,下一步可能需要一段时间,几个小时生成站点文档。
$ mvn install -DskipTests site assembly:single -Prelease
-
否则,当您尝试一步完成所有操作时,构建会抱怨hbase模块不在maven存储库中,尤其是在新的存储库中。您似乎需要在两个步骤中都需要安装目标。
-
提取生成的tarball - 你会在 hbase-assembly / target 下找到它并检查出来。查看文档,查看它是否运行等。如果好,请复制构建输出目录中源tarball旁边的tarball。
-
部署到Maven资源库。
接下来,将HBase部署到Apache Maven存储库。添加apache-release
profile when running themvn deploy`命令。此配置文件来自我们的pom文件引用的Apache父pom。只要 settings.xml 配置正确,它就会对发布到Maven的工件进行签名,如示例_〜/ .m2 / settings.xml_ 文件。此步骤取决于已由前一个bin tarball构建填充的本地存储库。$ mvn deploy -DskipTests -Papache-release -Prelease此命令将所有工件复制到处于“打开”状态的临时暂存Apache maven存储库。需要对这些maven工件进行更多的工作,以使它们普遍可用。
我们不会将HBase tarball发布到Apache Maven存储库。要避免部署tarball,请不要在
mvn deploy命令中包含assembly:single目标。检查已部署的工件,如下一节中所述。
make_rc.s
如果你运行_dev-support / make rc.sh 脚本,这就是你需要的。要完成发布,请从此处开始编写脚本。
-
使候选版本可用。
工件位于“打开”状态的暂存区域中的maven存储库中。在这种“开放”状态下,您可以查看您发布的内容,以确保一切顺利。为此,请使用您的Apache ID在 repository.apache.org 上登录Apache的Nexus。在临时存储库中查找工件。单击“Staging Repositories”并查找以“hbase”结尾的新状态,状态为“Open”,然后选择它。使用树视图展开存储库内容列表,并检查您期望的工件是否存在。检查POM。只要暂存存储仓库处于打开状态,您就可以在缺少某些内容或构建错误时重新上传。
如果出现严重错误并且您想要撤消上传,可以使用“删除”按钮删除和删除暂存存储库。有时上传在中间失败。这是您可能必须从暂存存储库中“删除”上载的另一个原因。
如果签出,请使用“关闭”按钮关闭仓库。必须先关闭存储库,然后才能使用它的公共URL。存储库可能需要几分钟才能关闭。完成后,您将在Nexus UI中看到存储库的公共URL。您可能还会收到一封包含该URL的电子邮件。在宣布候选发布版的电子邮件中提供临时登台存储库的URL。 (人们需要将此repo URL添加到其本地poms或其本地 settings.xml 文件中以提取已发布的候选工件。)
当发布投票成功结束时,返回此处并单击“发布”按钮以将工件发布到中央。发布过程将自动删除并删除暂存存储库。
> HBase的-downstreamer > > 请参阅 hbase-downstreamer 测试,了解HBase下游的项目的简单示例,具体取决于它。检查并运行其简单测试,以确保maven工件正确部署到maven存储库。请务必编辑pom以指向正确的临时存储库。确保在测试运行时从存储库中提取并且未从本地存储库获取,方法是传递
-U标志或删除本地存储库内容并检查maven是否已从远程存储库中移出。
有关此maven登台过程的一些指示,请参阅发布Maven工件。
-
如果HBase版本以
-SNAPSHOT结尾,则工件将转移到其他位置。它们直接放入Apache快照存储库并立即可用。发布SNAPSHOT,这就是您想要发生的事情。 -
在此阶段,您在“构建输出目录”中有两个tarball,并且在maven存储库的暂存区域中有一组工件处于“关闭”状态。下一个签名,指纹然后通过svnpubsub“释放”你的发布候选构建输出目录,将你的目录提交到开发分发目录(参见 HBASE-10554上的评论请从镜像系统中删除旧版本但实质上它是 dev / hbase 的svn结账 - 发布在发布/ hbase )。在_版本目录_中运行以下命令:
$ for i in *.tar.gz; do echo $i; gpg --print-md MD5 $i > $i.md5 ; done
$ for i in *.tar.gz; do echo $i; gpg --print-md SHA512 $i > $i.sha ; done
$ for i in *.tar.gz; do echo $i; gpg --armor --output $i.asc --detach-sig $i ; done
$ cd ..
# Presuming our 'build output directory' is named 0.96.0RC0, copy it to the svn checkout of the dist dev dir
# in this case named hbase.dist.dev.svn
$ cd /Users/stack/checkouts/hbase.dist.dev.svn
$ svn info
Path: .
Working Copy Root Path: /Users/stack/checkouts/hbase.dist.dev.svn
URL: https://dist.apache.org/repos/dist/dev/hbase
Repository Root: https://dist.apache.org/repos/dist
Repository UUID: 0d268c88-bc11-4956-87df-91683dc98e59
Revision: 15087
Node Kind: directory
Schedule: normal
Last Changed Author: ndimiduk
Last Changed Rev: 15045
Last Changed Date: 2016-08-28 11:13:36 -0700 (Sun, 28 Aug 2016)
$ mv 0.96.0RC0 /Users/stack/checkouts/hbase.dist.dev.svn
$ svn add 0.96.0RC0
$ svn commit ...
- 通过检查 https://dist.apache.org/repos/dist/dev/hbase/ 确保实际发布。
宣布邮件列表中的候选发布者并进行投票。
确保您的 settings.xml 设置正确(参见示例_〜/ .m2 / settings.xml_ 文件)。确保hbase版本包含-SNAPSHOT作为后缀。以下是发布其poms中hbase版本为0.96.0的发行版的SNAPSHOTS的示例。
$ mvn clean install -DskipTests javadoc:aggregate site assembly:single -Prelease
$ mvn -DskipTests deploy -Papache-release
上面提到的_make rc.sh 脚本(参见 maven.release )可以帮助您发布SNAPSHOTS。在运行脚本之前,请确保hbase.version后缀为-SNAPSHOT。它会将快照放入apache快照存储库中。
鼓励每个人尝试对HBase候选人进行投票。只有PMC成员的投票具有约束力。 PMC成员,请阅读关于候选发布候选人发布政策的政策投票的WIP文档。 [quote] 在投出1个绑定票之前,个人需要将签名的源代码包下载到他们自己的硬件上,按照提供的方式编译,并在自己的平台上测试生成的可执行文件,同时验证加密签名和验证该程序包符合ASF关于发布的策略的要求。 关注后者,运行+ mvn apache-rat:检查以验证所有文件是否获得适当许可。参见 HBase,mail#dev - 最近讨论澄清ASF发布政策。我们是如何到达这个过程的。
一旦RC成功通过并且所需的工件已经上演分配,您需要让每个人都知道我们闪亮的新版本。这不是一项要求,但为了让发布经理们更轻松,我们可以为您提供一个模板。请务必使用相关版本号替换_版本_和其他标记。您应该在发送之前手动验证所有链接。
The HBase team is happy to announce the immediate availability of HBase _version_.
Apache HBase™ is an open-source, distributed, versioned, non-relational database.
Apache HBase gives you low latency random access to billions of rows with
millions of columns atop non-specialized hardware. To learn more about HBase,
see https://hbase.apache.org/.
HBase _version_ is the _nth_ minor release in the HBase _major_.x line, which aims to
improve the stability and reliability of HBase. This release includes roughly
XXX resolved issues not covered by previous _major_.x releases.
Notable new features include:
- List text descriptions of features that fit on one line
- Including if JDK or Hadoop support versions changes
- If the "stable" pointer changes, call that out
- For those with obvious JIRA IDs, include them (HBASE-YYYYY)
The full list of issues can be found in the included CHANGES.md and RELEASENOTES.md,
or via our issue tracker:
https://s.apache.org/hbase-_version_-jira
To download please follow the links and instructions on our website:
https://hbase.apache.org/downloads.html
Question, comments, and problems are always welcome at: dev@hbase.apache.org.
Thanks to all who contributed and made this release possible.
Cheers,
The HBase Dev Team
您应将此消息发送到以下列表: dev@hbase.apache.org , user@hbase.apache.org , announce@apache.org 。如果您想在发送之前进行抽查,请随时通过jira或开发者列表询问。
该手册使用Asciidoc进行了标记。然后我们使用 Asciidoctor maven插件将标记转换为html。当您在运行mvn site时指定站点目标时,将运行此插件。有关构建文档的更多信息,请参阅文档的附录。
172.更新 hbase.apache.org
有关对文档或网站做出贡献的更多信息,请参阅文档的附录。
172.2。发布 hbase.apache.org
有关发布网站和文档的说明,请参阅发布HBase网站和文档。
开发人员至少应该熟悉单元测试细节; HBase中的单元测试具有其他项目中通常不会出现的特征。
此信息是关于HBase本身的单元测试。有关为HBase应用程序开发单元测试的信息,请参阅 unit.tests 。
截至0.96,Apache HBase分为多个模块。这为编写测试的方式和位置创建了“有趣的”规则。如果您正在为hbase-server编写代码,请参阅 hbase.unittests 以了解如何编写测试。这些测试可以启动minicluster并需要进行分类。对于任何其他模块,例如hbase-common,测试必须是严格的单元测试,并且只测试被测试的类 - 不允许使用HBaseTestingUtility或minicluster(或者甚至可以给定依赖树)。
HBase shell及其测试主要用jruby编写。
为了使这些测试作为标准构建的一部分运行,有一些JUnit测试类负责加载jruby实现的测试并运行它们。测试分为不同的类,以适应类级超时(详见单元测试)。您可以从顶层运行所有这些测试:
mvn clean test -Dtest=Test*Shell
如果您之前已经完成了mvn install,那么您可以指示maven仅运行hbase-shell模块中的测试:
mvn clean test -pl hbase-shell
或者,您可以限制使用系统变量shell.test运行的shell测试。此值应按名称指定特定测试用例的ruby文字等效项。例如,覆盖用于更改表的shell命令的测试包含在测试用例AdminAlterTableTest中,您可以使用以下命令运行它们:
mvn clean test -pl hbase-shell -Dshell.test=/AdminAlterTableTest/
您还可以使用 Ruby Regular Expression文字(/pattern/样式)来选择一组测试用例。您可以使用以下命令运行所有与HBase管理相关的测试,包括正常管理和安全管理:
mvn clean test -pl hbase-shell -Dshell.test=/.*Admin.*Test/
如果测试失败,您可以通过检查surefire报告结果的XML版本来查看详细信息
vim hbase-shell/target/surefire-reports/TEST-org.apache.hadoop.hbase.client.TestShell.xml
如果您正在开发的模块没有其他HBase模块的其他依赖项,那么您可以进入该模块并运行:
mvn test
这将只运行模块中的测试。如果其他模块存在其他依赖关系,那么您将从ROOT HBASE DIRECTORY运行该命令。这将在其他模块中运行测试,除非您指定跳过该模块中的测试。例如,要跳过hbase-server模块中的测试,您将运行:
mvn clean test -PskipServerTests
从顶级目录运行除hbase-server之外的模块中的所有测试。请注意,您可以指定跳过多个模块中的测试以及单个模块的测试。例如,要跳过hbase-server和hbase-common中的测试,您将运行:
mvn clean test -PskipServerTests -PskipCommonTests
另外,请记住,如果在hbase-server模块中运行测试,则需要应用 hbase.unittests.cmds 中讨论的maven配置文件,以使测试正常运行。
Apache HBase单元测试必须带有类别注释,从hbase-2.0.0开始,必须加上HBase ClassRule。以下是包含Category和ClassRule的Test Class的示例:
...
@Category(SmallTests.class)
public class TestHRegionInfo {
@ClassRule
public static final HBaseClassTestRule CLASS_RULE =
HBaseClassTestRule.forClass(TestHRegionInfo.class);
@Test
public void testCreateHRegionInfoName() throws Exception {
// ...
}
}
这里的测试类是TestHRegionInfo。 CLASS_RULE在每个测试类中具有相同的形式,只有你传递的.class是本地测试的形式;即在TestTimeout测试类中,你将TestTimeout.class传递给CLASS_RULE而不是我们上面的TestHRegionInfo.class。 CLASS_RULE是我们强制执行超时的(目前设置为所有测试的硬限制为13分钟 - 780秒)和其他跨单元测试设施。测试在SmallTest类别中。
类别可以是任意的,并作为列表提供,但每个测试必须携带以下列表中的一个:small,medium,large和integration。使用JUnit 类别:SmallTests,MediumTests,LargeTests,IntegrationTests指定测试大小。 JUnit类别使用java注释表示(特殊单元测试在所有单元tess中查找@Category注释的存在,如果发现测试套件缺少大小标记,则会失败)。
前三个类别small,medium和large用于键入$ mvn test时运行的测试用例。换句话说,这三个分类用于HBase单元测试。 integration类别不是用于单元测试,而是用于集成测试。这些通常在您调用$ mvn verify时运行。集成测试在 integration.tests 中描述。
继续阅读以确定新的HBase测试用例上的集合small,medium和large的注释。
分类测试
小测试
_小型_测试用例在共享JVM中执行,每个测试套件/测试类应在15秒或更短时间内运行;即一个 junit测试夹具,一个由测试方法组成的java对象,应该在15秒内完成,无论它有多少或几乎没有测试方法。这些测试用例不应使用minicluster。
中等测试
_中_测试用例在单独的JVM和单独的测试套件或测试类中执行,或者以junit的说法执行,测试夹具应该在50秒或更短的时间内运行。这些测试用例可以使用迷你集群。
大型测试
_大型_测试案例就是其他一切。它们通常是大规模测试,特定错误的回归测试,超时测试或性能测试。没有大型测试套件可能需要超过十分钟。随着时间的推移会被杀死。如果需要运行更长时间,请将测试作为集成测试。
集成测试
_集成_测试是系统级测试。有关详细信息,请参阅 integration.tests 。如果在集成测试中调用$ mvn test,则测试没有超时。
运行mvn test将在单个JVM(无分支)中执行所有小测试,然后在单独的JVM中为每个测试实例执行中等测试。如果小测试中存在错误,则不执行中等测试。不执行大型测试。
运行mvn test -P runAllTests将在单个JVM中执行小型测试,然后在单独的JVM中为每个测试执行中型和大型测试。如果小测试中存在错误,则不执行中型和大型测试。
要进行单独测试,例如MyTest,朗姆酒mvn test -Dtest=MyTest您还可以将多个单独的测试作为逗号分隔列表传递:
mvn test -Dtest=MyTest1,MyTest2,MyTest3
您还可以传递一个包,它将运行包下的所有测试:
mvn test '-Dtest=org.apache.hadoop.hbase.client.*'
指定-Dtest时,将使用localTests配置文件。每个junit测试都在一个单独的JVM(每个测试类的一个fork)中执行。在此模式下运行测试时没有并行化。您将在-report的末尾看到一条新消息:"[INFO] Tests are skipped"。这是无害的。但是,您需要确保测试报告的Results:部分中Tests run:的总和与您指定的测试数相匹配,因为在指定不存在的测试用例时不会报告错误。
运行mvn test -P runSmallTests将仅使用单个JVM执行“小”测试。
运行mvn test -P runMediumTests将仅执行“中”测试,为每个测试类启动一个新的JVM。
运行mvn test -P runLargeTests将仅执行“大型”测试,为每个测试类启动一个新的JVM。
为方便起见,您可以使用单个JVM运行mvn test -P runDevTests来执行小型和中型测试。
默认情况下,$ mvn test -P runAllTests并行运行5个测试。它可以在开发人员的机器上增加。允许每个核心可以并行进行2次测试,每次测试需要大约2GB内存(在极端情况下),如果你有8核24GB盒子,你可以并行进行16次测试。但可用内存将其限制为12(24/2),要并行执行12次测试的所有测试,请执行以下操作:mvn test -P runAllTests -Dsurefire.secondPartForkCount = 12。如果使用早于2.0的版本,请执行:+ mvn test -P runAllTests -Dsurefire.secondPartThreadCount = 12 +。要提高速度,您也可以使用ramdisk。您将需要2GB的内存来运行所有测试。您还需要在两次测试运行之间删除文件。在Linux上配置ramdisk的典型方法是:
$ sudo mkdir /ram2G
sudo mount -t tmpfs -o size=2048M tmpfs /ram2G
然后,您可以使用以下命令在2.0上运行所有HBase测试:
mvn test
-P runAllTests -Dsurefire.secondPartForkCount=12
-Dtest.build.data.basedirectory=/ram2G
在早期版本中,使用:
mvn test
-P runAllTests -Dsurefire.secondPartThreadCount=12
-Dtest.build.data.basedirectory=/ram2G
也可以使用脚本hbasetests.sh。此脚本与两个maven实例并行运行中型和大型测试,并提供单个报告。此脚本不使用surefire的hbase版本,因此除了脚本设置的两个maven实例之外,不会进行任何并行化。它必须从包含 pom.xml 的目录执行。
例如,运行./dev-support/hbasetests.sh将执行中小型测试。运行./dev-support/hbasetests.sh runAllTests将执行所有测试。运行./dev-support/hbasetests.sh replayFailed将在单独的jvm中重新运行失败的测试,并且没有并行化。
不严格执行HBase单元测试大小分类超时。
任何运行时间超过十分钟的测试都将超时/终止。
从hbase-2.0.0开始,我们已经清除了所有的每个测试方法超时:即
...
@Test(timeout=30000)
public void testCreateHRegionInfoName() throws Exception {
// ...
}
考虑到我们是整个测试夹具/类/套件需要多长时间的基础,并且测试方法所需的时间差异在很大程度上取决于上下文(加载的Apache基础设施与开发人员机器),因此他们不鼓励并且没有多大意义没有别的东西在上面运行)。
自定义Maven SureFire插件监听器在每个HBase单元测试运行之前和之后检查许多资源,并在测试输出文件的末尾记录其结果,这些文件可以在每个Maven模块的 target / surefire-reports 中找到(测试将为测试类命名的测试报告写入此目录。检查 * -out.txt 文件)。计算的资源是线程数,文件描述符数等。如果数量增加,它会增加 LEAK? 在日志中发表评论。由于您可以在后台运行HBase实例,因此可以删除/创建一些线程,而无需在测试中执行任何特定操作。但是,如果测试不能按预期工作,或者测试不会影响这些资源,则值得检查这些日志行... hbase.ResourceChecker(157):before ...和... hbase.ResourceChecker(157 ):之后....例如:
2012-09-26 09:22:15,315 INFO [pool-1-thread-1]
hbase.ResourceChecker(157): after:
regionserver.TestColumnSeeking#testReseeking Thread=65 (was 65),
OpenFileDescriptor=107 (was 107), MaxFileDescriptor=10240 (was 10240),
ConnectionCount=1 (was 1)
-
尽可能将测试编写为类别小测试。
-
必须编写所有测试以支持在同一台机器上并行执行,因此它们不应将共享资源用作固定端口或固定文件名。
-
测试不应该过度。超过100行/秒使得日志复杂化以便读取和使用i / o,因此不能用于其他测试。
-
可以使用
HBaseTestingUtility编写测试。此类提供辅助函数来创建临时目录并执行清理或启动集群。
-
必须对所有测试进行分类,否则可以跳过它们。
-
所有测试都应尽可能快地编写。
-
见&lt; <hbase.unittests>用于测试用例类别和相应的超时。这应确保使用它的人员具有良好的并行性,并在测试失败时简化分析。</hbase.unittests>
只要有可能,测试不应该使用Thread.sleep,而是等待他们需要的真实事件。这对读者来说更快更清晰。测试不应该在没有测试结束条件的情况下执行Thread.sleep。这样可以了解测试正在等待的内容。而且,无论机器性能如何,测试都能正常工作。睡眠应该尽可能快。等待变量应该在40ms的睡眠循环中完成。等待套接字操作应该在200毫秒的睡眠循环中完成。
使用HRegion进行的测试不必启动集群:区域可以使用本地文件系统。启动/停止群集成本大约10秒。它们不应该按照测试方法而是按测试类启动。必须使用HBaseTestingUtility#shutdownMiniCluster关闭已启动的集群,该程序清除目录。尽可能多地,测试应使用群集的默认设置。如果他们不这样做,他们应该记录下来。这将允许稍后共享群集。
这是一个带有分类和基于类别的超时规则的测试框架代码,用于复制和粘贴并用作测试贡献的基础。
/**
* Describe what this testcase tests. Talk about resources initialized in @BeforeClass (before
* any test is run) and before each test is run, etc.
*/
// Specify the category as explained in <<hbase.unittests,hbase.unittests>>.
@Category(SmallTests.class)
public class TestExample {
// Replace the TestExample.class in the below with the name of your test fixture class.
private static final Log LOG = LogFactory.getLog(TestExample.class);
// Handy test rule that allows you subsequently get the name of the current method. See
// down in 'testExampleFoo()' where we use it to log current test's name.
@Rule public TestName testName = new TestName();
// The below rule does two things. It decides the timeout based on the category
// (small/medium/large) of the testcase. This @Rule requires that the full testcase runs
// within this timeout irrespective of individual test methods' times. The second
// feature is we'll dump in the log when the test is done a count of threads still
// running.
@Rule public static TestRule timeout = CategoryBasedTimeout.builder().
withTimeout(this.getClass()).withLookingForStuckThread(true).build();
@Before
public void setUp() throws Exception {
}
@After
public void tearDown() throws Exception {
}
@Test
public void testExampleFoo() {
LOG.info("Running test " + testName.getMethodName());
}
}
HBase集成/系统测试是超出HBase单元测试的测试。它们通常是持久的,相当大的(测试可以被要求为1M行或1B行),可以定位(它们可以采取配置,将它们指向它们要运行的现成集群;集成测试不包括集群启动/停止代码),并验证成功,集成测试仅依赖于公共API;他们不会尝试检查服务器内部断言成功/失败。当您需要对单元测试可以执行的发布候选项进行更详细的校对时,您将运行集成测试。它们通常不在Apache Continuous Integration构建服务器上运行,但是,一些站点选择运行集成测试作为其在实际集群上进行连续测试的一部分。
集成测试目前位于hbase-it子模块中的 src / test 目录下,并且将匹配正则表达式: *** / IntegrationTest** .java 。所有集成测试也使用@Category(IntegrationTests.class)进行注释。
集成测试可以以两种模式运行:使用迷你集群,或针对实际的分布式集群。 Maven failsafe用于使用迷你集群运行测试。 IntegrationTestsDriver类用于对分布式集群执行测试。集成测试不应该假设它们是针对迷你集群运行的,并且不应该使用私有API来访问集群状态。要统一地与分布式或迷你集群交互,可以使用IntegrationTestingUtility和HBaseCluster类以及公共客户端API。
在分布式群集上,使用ChaosMonkey的集成测试或通过集群管理器(例如,重新启动区域服务器)操纵服务的集成测试使用SSH来执行此操作。要运行这些,测试进程应该能够在远程端运行命令,因此应该相应地配置ssh(例如,如果HBase在集群中的hbase用户下运行,则可以为该用户设置无密码ssh并运行测试在它下面)。为此,可以使用hbase.it.clustermanager.ssh.user,hbase.it.clustermanager.ssh.opts和hbase.it.clustermanager.ssh.cmd配置设置。 “User”是集群管理器用于执行ssh命令的远程用户。 “Opts”包含传递给SSH的其他选项(例如,“ - i / tmp / my-key”)。最后,如果您有一些自定义环境设置,“cmd”是整个隧道(ssh)命令的覆盖格式。默认字符串是{/usr/bin/ssh %1$s %2$s%3$s%4$s "%5$s"},是一个很好的起点。这是一个标准的Java格式字符串,带有5个参数,用于执行远程命令。参数1(%1 $ s)是SSH选项设置via opts设置或通过环境变量,2是SSH用户名,如果设置了username,则3是“@”,否则,“4”是目标主机名,并且5是要执行的逻辑命令(可能包括单引号,因此不要使用它们)。例如,如果您在非hbase用户下运行测试并希望ssh作为该用户并在远程计算机上更改为hbase,则可以使用:
/usr/bin/ssh %1$s %2$s%3$s%4$s "su hbase - -c \"%5$s\""
这样,杀死RS(例如)集成测试可能会运行:
{/usr/bin/ssh some-hostname "su hbase - -c \"ps aux | ... | kill ...\""}
该命令记录在测试日志中,因此您可以验证它是否适合您的环境。
要禁用集成测试的运行,请在命令行-PskipIntegrationTests上传递以下配置文件。例如,
$ mvn clean install test -Dtest=TestZooKeeper -PskipIntegrationTests
HBase 0.92添加了verify maven目标。调用它,例如通过执行mvn verify,将通过maven 故障安全插件运行所有阶段,包括验证阶段,运行所有上述HBase单元测试以及中的测试HBase集成测试组。完成mvn install -DskipTests后,您可以通过调用以下命令运行集成测试:
cd hbase-it
mvn verify
如果您只想在顶层运行集成测试,则需要运行两个命令。第一:mvn failsafe:integration-test这实际上运行所有集成测试。
即使存在测试失败,该命令也将始终输出
BUILD SUCCESS。
此时,您可以手动查找输出失败的测试。但是,maven会为我们这样做;只需使用:mvn failsafe:verify上面的命令基本上查看了测试失败的所有测试结果(因此不要删除'target'目录)并报告结果。
这与您指定运行单元测试子集(参见上文)的方式非常相似,但使用属性it.test而不是test。要运行IntegrationTestClassXYZ.java,请使用:mvn failsafe:integration-test -Dit.test = IntegrationTestClassXYZ您可能要做的下一件事是运行集成测试组,例如所有名为IntegrationTestClassX .java的集成测试: mvn failsafe:integration-test -Dit.test = ClassX 这将运行与 ClassX 匹配的集成测试。这意味着任何匹配:“** / IntegrationTest ClassX **”。您还可以使用逗号分隔列表运行多组集成测试(类似于单元测试)。使用匹配列表仍支持每个组的完整正则表达式匹配。这看起来像:mvn failsafe:integration-test -Dit.test = ClassX , ClassY
如果您已经安装了HBase集群,则可以通过调用类IntegrationTestsDriver来启动集成测试。您可能必须先运行test-compile。配置将由bin / hbase脚本选取。
mvn test-compile
然后启动测试:
bin/hbase [--config config_dir] org.apache.hadoop.hbase.IntegrationTestsDriver
通过-h来使用这个甜蜜的工具。不带任何参数运行IntegrationTestsDriver将启动在hbase-it/src/test下找到的测试,具有@Category(IntegrationTests.class)注释,名称以IntegrationTests开头。通过传递-h来查看用法,以了解如何过滤测试类。您可以传递一个正则表达式,该正则表达式将根据完整的类名进行检查;所以,可以使用类名的一部分。 IntegrationTestsDriver使用Junit来运行测试。目前,不支持使用maven对分布式集群运行集成测试(参见 HBASE-6201 )。
测试通过使用DistributedHBaseCluster(实现HBaseCluster)类中的方法与分布式集群交互,后者又使用可插入的ClusterManager。具体实现提供了用于执行特定于部署和环境的任务(SSH等)的实际功能。默认ClusterManager是HBaseClusterManager,它使用SSH远程执行start / stop / kill / signal命令,并假设一些posix命令(ps等)。还假设运行测试的用户具有足够的“电源”来启动/停止远程计算机上的服务器。默认情况下,它从env中获取HBASE_SSH_OPTS,HBASE_HOME,HBASE_CONF_DIR,并使用bin/hbase-daemon.sh执行操作。目前支持tarball部署,使用 hbase-daemons.sh 和 Apache Ambari 部署的部署。 /etc/init.d/ 脚本现在不受支持,但可以轻松添加。对于其他部署选项,可以实现和插入ClusterManager。
HBase 0.96引入了一个名为ChaosMonkey的工具,该工具以Netflix的混沌猴工具的同名工具为蓝本。 ChaosMonkey通过终止或断开随机服务器或将其他故障注入环境来模拟正在运行的集群中的实际故障。您可以使用ChaosMonkey作为独立工具在其他测试运行时运行策略。在某些环境中,ChaosMonkey始终在运行,以便不断检查高可用性和容错是否按预期工作。
ChaosMonkey定义动作和策略。
操作
操作是预定义的事件序列,例如:
-
重启活动主人(睡5秒)
-
重启随机区域服务器(睡5秒)
-
重启随机区域服务器(睡眠60秒)
-
重启META regionserver(睡5秒)
-
重启ROOT regionserver(睡5秒)
-
批量重启50%的区域服务器(睡眠5秒)
-
滚动重启100%的区域服务器(睡眠5秒)
政策
策略是用于执行一个或多个动作的策略。默认策略基于预定义的操作权重每分钟执行一次随机操作。在ChaosMonkey中断之前,将执行给定的策略。
大多数ChaosMonkey操作都配置为具有合理的默认值,因此您可以针对现有群集运行ChaosMonkey,而无需任何其他配置。以下示例使用默认配置运行ChaosMonkey:
$ bin/hbase org.apache.hadoop.hbase.util.ChaosMonkey
12/11/19 23:21:57 INFO util.ChaosMonkey: Using ChaosMonkey Policy: class org.apache.hadoop.hbase.util.ChaosMonkey$PeriodicRandomActionPolicy, period:60000
12/11/19 23:21:57 INFO util.ChaosMonkey: Sleeping for 26953 to add jitter
12/11/19 23:22:24 INFO util.ChaosMonkey: Performing action: Restart active master
12/11/19 23:22:24 INFO util.ChaosMonkey: Killing master:master.example.com,60000,1353367210440
12/11/19 23:22:24 INFO hbase.HBaseCluster: Aborting Master: master.example.com,60000,1353367210440
12/11/19 23:22:24 INFO hbase.ClusterManager: Executing remote command: ps aux | grep master | grep -v grep | tr -s ' ' | cut -d ' ' -f2 | xargs kill -s SIGKILL , hostname:master.example.com
12/11/19 23:22:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:
12/11/19 23:22:25 INFO hbase.HBaseCluster: Waiting service:master to stop: master.example.com,60000,1353367210440
12/11/19 23:22:25 INFO hbase.ClusterManager: Executing remote command: ps aux | grep master | grep -v grep | tr -s ' ' | cut -d ' ' -f2 , hostname:master.example.com
12/11/19 23:22:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:
12/11/19 23:22:25 INFO util.ChaosMonkey: Killed master server:master.example.com,60000,1353367210440
12/11/19 23:22:25 INFO util.ChaosMonkey: Sleeping for:5000
12/11/19 23:22:30 INFO util.ChaosMonkey: Starting master:master.example.com
12/11/19 23:22:30 INFO hbase.HBaseCluster: Starting Master on: master.example.com
12/11/19 23:22:30 INFO hbase.ClusterManager: Executing remote command: /homes/enis/code/hbase-0.94/bin/../bin/hbase-daemon.sh --config /homes/enis/code/hbase-0.94/bin/../conf start master , hostname:master.example.com
12/11/19 23:22:31 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:starting master, logging to /homes/enis/code/hbase-0.94/bin/../logs/hbase-enis-master-master.example.com.out
....
12/11/19 23:22:33 INFO util.ChaosMonkey: Started master: master.example.com,60000,1353367210440
12/11/19 23:22:33 INFO util.ChaosMonkey: Sleeping for:51321
12/11/19 23:23:24 INFO util.ChaosMonkey: Performing action: Restart random region server
12/11/19 23:23:24 INFO util.ChaosMonkey: Killing region server:rs3.example.com,60020,1353367027826
12/11/19 23:23:24 INFO hbase.HBaseCluster: Aborting RS: rs3.example.com,60020,1353367027826
12/11/19 23:23:24 INFO hbase.ClusterManager: Executing remote command: ps aux | grep regionserver | grep -v grep | tr -s ' ' | cut -d ' ' -f2 | xargs kill -s SIGKILL , hostname:rs3.example.com
12/11/19 23:23:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:
12/11/19 23:23:25 INFO hbase.HBaseCluster: Waiting service:regionserver to stop: rs3.example.com,60020,1353367027826
12/11/19 23:23:25 INFO hbase.ClusterManager: Executing remote command: ps aux | grep regionserver | grep -v grep | tr -s ' ' | cut -d ' ' -f2 , hostname:rs3.example.com
12/11/19 23:23:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:
12/11/19 23:23:25 INFO util.ChaosMonkey: Killed region server:rs3.example.com,60020,1353367027826\. Reported num of rs:6
12/11/19 23:23:25 INFO util.ChaosMonkey: Sleeping for:60000
12/11/19 23:24:25 INFO util.ChaosMonkey: Starting region server:rs3.example.com
12/11/19 23:24:25 INFO hbase.HBaseCluster: Starting RS on: rs3.example.com
12/11/19 23:24:25 INFO hbase.ClusterManager: Executing remote command: /homes/enis/code/hbase-0.94/bin/../bin/hbase-daemon.sh --config /homes/enis/code/hbase-0.94/bin/../conf start regionserver , hostname:rs3.example.com
12/11/19 23:24:26 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:starting regionserver, logging to /homes/enis/code/hbase-0.94/bin/../logs/hbase-enis-regionserver-rs3.example.com.out
12/11/19 23:24:27 INFO util.ChaosMonkey: Started region server:rs3.example.com,60020,1353367027826\. Reported num of rs:6
输出表明ChaosMonkey启动了默认的PeriodicRandomActionPolicy策略,该策略配置了所有可用的操作。它选择运行RestartActiveMaster和RestartRandomRs动作。
HBase附带了几个ChaosMonkey策略,可在hbase/hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/policies/目录中找到。
可以在每次测试运行中配置ChaosMonkey集成测试。在HBase CLASSPATH中创建Java属性文件,并使用-monkeyProps配置标志将其传递给ChaosMonkey。可配置属性及其默认值(如果适用)列在org.apache.hadoop.hbase.chaos.factories.MonkeyConstants类中。对于具有默认值的属性,可以通过将它们包含在属性文件中来覆盖它们。
以下示例使用名为 monkey.properties 的属性文件。
$ bin/hbase org.apache.hadoop.hbase.IntegrationTestIngest -m slowDeterministic -monkeyProps monkey.properties
上面的命令将启动集成测试和混乱猴子。它将在HBase CLASSPATH上查找属性文件 monkey.properties ;例如在HBASE conf dir里面。
这是一个混乱的猴子文件示例:
示例ChaosMonkey属性文件
sdm.action1.period=120000
sdm.action2.period=40000
move.regions.sleep.time=80000
move.regions.max.time=1000000
move.regions.sleep.time=80000
batch.restart.rs.ratio=0.4f
周期/时间以毫秒表示。
HBase 1.0.2和更新版本增加了重启HBase底层ZooKeeper仲裁或HDFS节点的能力。要使用这些操作,您需要在ChaosMonkey属性文件中配置一些新属性,这些属性没有合理的默认值,因为它们是特定于部署的,可能是hbase-site.xml或不同的属性文件。
<property>
<name>hbase.it.clustermanager.hadoop.home</name>
<value>$HADOOP_HOME</value>
</property>
<property>
<name>hbase.it.clustermanager.zookeeper.home</name>
<value>$ZOOKEEPER_HOME</value>
</property>
<property>
<name>hbase.it.clustermanager.hbase.user</name>
<value>hbase</value>
</property>
<property>
<name>hbase.it.clustermanager.hadoop.hdfs.user</name>
<value>hdfs</value>
</property>
<property>
<name>hbase.it.clustermanager.zookeeper.user</name>
<value>zookeeper</value>
</property>
我们使用Git进行源代码管理,并在master分支上进行最新的开发。过去的主要/次要/维护版本都有分支,重要的功能和错误修复通常会反向移植到它们。
界面按受众和稳定性级别进行分类。这些标签出现在班级的头部。 HBase遵循的约定由其父项目Hadoop继承。
通常使用以下接口分类:
InterfaceAudience
@InterfaceAudience.Public
用户和HBase应用程序的API。这些API将通过主要版本的HBase弃用。
@InterfaceAudience.Private
HBase内部开发人员的API。在将来的版本中不保证兼容性或可用性。专用接口不需要@InterfaceStability分类。
@InterfaceAudience.LimitedPrivate(HBaseInterfaceAudience.COPROC)
HBase协处理器编写器的API。
没有@InterfaceAudience分类
没有@InterfaceAudience标签的包被视为私有。如果可以公开访问,请标记新包。
从API文档中排除非公共接口
只有分类
@InterfaceAudience.Public的接口才应包含在API文档(Javadoc)中。对于不包含公共类的新包,提交者必须为 pom.xml 添加新包,不包括ExcludePackageNames部分。
@InterfaceStability
@InterfaceStability对标有@InterfaceAudience.Public的包很重要。
@InterfaceStability.Stable
如果没有弃用路径或非常好的理由,则无法更改标记为稳定的公共包。
@InterfaceStability.Unstable
标记为不稳定的公共包可以在没有弃用路径的情况下进行更改。
@InterfaceStability.Evolving
标记为演变的公共包可能会被更改,但不鼓励使用。
没有@InterfaceStability标签
不鼓励没有@InterfaceStability标签的公共类,并且应该将其视为隐式不稳定。
如果您不清楚如何标记包,请在开发列表中询问。
请遵循以下准则,以便更快地审核您的补丁。这些指南是基于对新贡献者的补丁的共同反馈而开发的。
有关Java编码约定的更多信息,请参见 Java编程语言的代码约定。请参阅 eclipse.code.formatting 以设置Eclipse以自动检查其中一些指南。
不要在括号周围使用额外的空格。使用第二种风格,而不是第一种风格。
if ( foo.equals( bar ) ) { // don't do this
if (foo.equals(bar)) {
foo = barArray[ i ]; // don't do this
foo = barArray[i];
Eclipse中自动生成的代码通常使用错误的变量名,例如arg0。使用更具信息性的变量名称。像这里的第二个例子一样使用代码。
public void readFields(DataInput arg0) throws IOException { // don't do this
foo = arg0.readUTF(); // don't do this
public void readFields(DataInput di) throws IOException {
foo = di.readUTF();
保持行少于100个字符。您可以将IDE配置为自动执行此操作。
Bar bar = foo.veryLongMethodWithManyArguments(argument1, argument2, argument3, argument4, argument5, argument6, argument7, argument8, argument9); // don't do this
Bar bar = foo.veryLongMethodWithManyArguments(
argument1, argument2, argument3,argument4, argument5, argument6, argument7, argument8, argument9);
确保在代码结束后有一个换行符,并避免只有空格的行。这使得差异更有意义。您可以配置IDE以帮助解决此问题。
Bar bar = foo.getBar(); <--- imagine there is an extra space(s) after the semicolon.
别忘了Javadoc!
在预先提交期间检查Javadoc警告。如果预先提交工具给你一个'-1',请修复javadoc问题。如果添加此类警告,则不会提交您的补丁。
此外,没有@author标签 - 这是一个规则。
Findbugs用于检测常见错误模式。在precommit构建期间检查它。如果发现错误,请修复它们。您可以使用mvn findbugs:findbugs在本地运行findbugs,它将在本地生成findbugs文件。有时,您可能必须编写比findbugs更智能的代码。您可以通过使用以下注释对类进行注释来注释代码以告诉findbugs您知道自己在做什么:
@edu.umd.cs.findbugs.annotations.SuppressWarnings(
value="HE_EQUALS_USE_HASHCODE",
justification="I know what I'm doing")
使用Apache许可版本的注释很重要。这通常意味着在edu.umd.cs.findbugs.annotations包中使用注释,这样我们就可以依赖于洁净室重新实现而不是javax.annotations包中的注释。
不要像IDE生成它们那样保留javadoc标记,也不要在其中填充冗余信息。
/**
* @param table <---- don't leave them empty!
* @param region An HRegion object. <---- don't fill redundant information!
* @return Foo Object foo just created. <---- Not useful information
* @throws SomeException <---- Not useful. Function declarations already tell that!
* @throws BarException when something went wrong <---- really?
*/
public Foo createFoo(Bar bar);
添加描述符号的内容,或者只删除它们。首选是添加描述性和有用的东西。
如果您为一件事提交补丁,请不要在完全不同的代码区域上进行自动重新格式化或不相关的代码重新格式化。
同样,不要在Jira的范围之外添加不相关的清理或重构。
确保您清楚自己在单元测试中测试的内容以及原因。
适用于0.96之前的版本
在0.96中,HBase转移到协议缓冲区(protobufs)。关于Writables的以下部分适用于0.94.x及之前,而不是0.96及更高版本。
RegionServers返回的每个类都必须实现Writable接口。如果要创建需要实现此接口的新类,请不要忘记默认构造函数。
以下指南来自 http://engineering.linkedin.com/performance/linkedin-feed-faster-less-jvm-garbage 。牢记这一点,将可预防的垃圾收集工作降至最低。请查看博客文章,了解如何根据这些指南重构代码的一些很好的示例。
-
对迭代器要小心
-
初始化时估计集合的大小
-
推迟表达评估
-
提前编译正则表达式模式
-
如果可以,请缓存它
-
字符串实习生很有用但很危险
我们没有很多,但我们在下面列出了什么。当然所有都受到挑战,但在此之前,请遵守道路规则。
ZooKeeper状态应该是瞬态的(将其视为内存)。如果删除ZooKeeper状态,hbase应该能够恢复并且基本上处于相同的状态。
-
.Exceptions:目前我们需要解决几个例外,无论表是启用还是禁用。
-
复制数据当前仅存储在ZooKeeper中。删除与复制相关的ZooKeeper数据可能会导致禁用复制。不要删除复制树, / hbase / replication / 。
> 如果从ZooKeeper中删除复制树( / hbase / replication / ),则可能会中断复制并导致数据丢失。在 HBASE-10295 上关注此问题的进展。
如果您正在开发Apache HBase,那么测试您对更真实的集群的更改通常比您在单元测试中找到的更有用。在这种情况下,HBase可以在本地模式下直接从源运行。您需要做的就是运行:
${HBASE_HOME}/bin/start-hbase.sh
这将启动一个完整的本地群集,就像您已打包HBase并将其安装在您的计算机上一样。
请记住,您需要将HBase安装到本地maven存储库中,以使原位群集正常工作。也就是说,您需要运行:
mvn clean install -DskipTests
确保maven可以找到正确的类路径和依赖项。一般来说,如果maven行为奇怪,上面的命令首先尝试运行是一件好事。
添加新功能后,开发人员可能希望添加指标。 HBase使用Hadoop Metrics 2系统公开指标,因此添加新指标涉及将该指标公开给hadoop系统。不幸的是,metrics2的API从hadoop 1变为hadoop 2.为了解决这个问题,必须在运行时加载一组接口和实现。要深入了解这些类的推理和结构,您可以阅读这里的博客文章。要向现有MBean添加指标,请遵循以下简短指南:
在源接口内部,对应于生成度量的位置(例如,来自HMaster的事物的MetricsMasterSource)为度量标准名称和描述创建新的静态字符串。然后添加一个将被调用以添加新读数的新方法。
在源的实现内部(例如,上例中的MetricsMasterSourceImpl)在init方法中创建新的直方图,计数器,计量器或stat。然后在添加到接口的方法中连接传入直方图的参数。
现在添加测试以确保数据正确导出到metrics 2系统。为此,提供了MetricsAssertHelper。
避免git合并。
使用git pull --rebase或git fetch,然后按git rebase。
不要使用git push --force。
如果推送不起作用,请解决问题或寻求帮助。
如果您考虑其他Git最佳实践,请参与此文档。
提供了_dev-support / rebase_all_git branches.sh 脚本以帮助保持Git存储库的清洁。使用-h参数获取使用说明。该脚本会自动刷新您的跟踪分支,尝试针对其远程分支自动重新定位每个本地分支,并为您提供删除代表已关闭HBASE- JIRA的任何分支的选项。该脚本有一个可选的配置选项,即Git目录的位置。您可以通过编辑脚本来设置默认值。否则,您可以使用-d参数手动传递git目录,然后使用绝对或相对目录名称,甚至是“。”对于当前的工作目录。在继续之前,脚本会检查目录中是否有名为 .git / 的子目录。
如果您不熟悉提交补丁到开源或新提交补丁到Apache,请首先阅读 Apache Commons Project 中的 On Contributing Patches 页面。它提供了一个很好的概述,同样适用于Apache HBase项目。
请务必查看 common.patch.feedback 的代码样式。如果您的补丁生成不正确或您的代码不符合代码格式指南,则可能会要求您重做某些工作。
使用submit-patch.py(推荐)
$ dev-support/submit-patch.py -jid HBASE-xxxxx
使用此脚本创建修补程序,上传到jira并可选择在Review Board上创建/更新评论。补丁名称自动格式化为_(JIRA)。(分支名称)。(补丁号)。补丁_遵循Yetus的命名规则。使用-h标志了解详细的使用信息。最有用的选项是:
-
-b BRANCH, --branch BRANCH:指定用于生成diff的基本分支。如果未指定,则使用跟踪分支。如果没有跟踪分支,则会抛出错误。 -
-jid JIRA_ID, --jira-id JIRA_ID:如果使用,则从jira中的附件推断下一个补丁版本并上传新补丁。脚本将要求jira用户名/密码进行身份验证。如果未设置,则将补丁命名为 <branch>.patch。</branch>
默认情况下,它还会创建/更新审核委员会。要跳过该操作,请使用-srb选项。它使用jira中的“问题链接”来确定审核请求是否已存在。如果没有审核请求,则创建一个新请求并使用jira摘要,补丁说明等填充所有必填字段。此外,还将此评论的链接添加到jira。
保存身份验证凭据(可选)
由于在JIRA上附加补丁并在ReviewBoard上创建/更改审阅请求需要有效的用户身份验证,因此脚本将提示您输入用户名和密码。为了避免每次麻烦,请使用登录详细信息设置~/.apache-creds并按照脚本帮助消息页脚中的步骤对其进行加密。
Python依赖项
要安装所需的python依赖项,请从master分支执行pip install -r dev-support/python-requirements.txt。
手动
-
首先使用
git rebase -i,将较小的提交组合(压缩)到一个较大的提交中。 -
使用IDE或Git命令创建补丁。
git format-patch是首选,因为它保留了补丁作者的姓名和提交消息。此外,它默认处理二进制文件,而git diff忽略它们,除非您使用--binary选项。 -
补丁名称应如下符合Yetus的命名约定:
(JIRA).(branch name).(patch number).patch例如。 HBASE-11625.master.001.patch,HBASE-XXXXX.branch-1.2.0005.patch等 -
使用
More→Attach Files将补丁附加到JIRA,然后单击 Submit Patch 按钮,这将触发Hudson作业以检查补丁的有效性。 -
如果您的补丁长于单个屏幕,还可以在Review Board上创建评论并添加指向JIRA的链接。参见评论板。
一般指导原则很少
-
即使您要在另一个分支中进行修补,也要始终首先修补主分支。 HBase提交程序始终首先将修补程序应用于主分支,并在必要时应用反向端口。
-
提交一个修补程序的单个修补程序。如有必要,首先将本地提交压缩为单个提交。有关压缩提交的更多信息,请参阅此堆栈溢出问题。
-
请理解并非每个补丁都可能会被提交,并且可能会在补丁上提供反馈。
-
如果您需要修改补丁,请将之前的补丁文件保留在JIRA上,然后上传一个补丁编号增加的补丁文件。单击取消补丁,然后单击提交补丁以触发预提交运行。
在进行更改时始终添加和/或更新相关的单元测试。在提交补丁之前确保新的/更改的单元测试在本地通过,因为它比等待运行完整测试套件的预提交结果更快。这将节省您自己的时间和精力。使用 mockito 制作模拟,这些模拟对于通过注入适当的故障来测试故障情况非常有用。
如果要创建新的单元测试类,请注意其他单元测试类在类名称之前是否具有分类/大小调整注释以及用于设置/拆除测试环境的静态方法。请务必在任何新的单元测试文件中包含注释。有关测试的更多信息,请参见 hbase.tests 。
除了单元测试之外,重要的新功能还应提供集成测试,适用于在其配置空间的不同点执行新功能。
大于一个屏幕的补丁或者难以查看的补丁应该通过 ReviewBoard 。
过程:使用ReviewBoard
-
如果您还没有帐户,请注册一个帐户。它不使用 issues.apache.org 的凭据。登录。
-
单击“新建审阅请求”
-
选择
hbase-git存储库。单击“选择文件”以选择差异和可选的父差异。单击创建审核请求。 -
根据需要填写字段。至少,填写摘要并选择
hbase作为审核组。如果您填写Bugs字段,审核委员会会链接回相关的JIRA。您填写的字段越多越好。点击发布即可公开您的评论请求。将向hbase组中的每个人发送一封电子邮件,以查看该补丁。 -
返回JIRA,单击并粘贴ReviewBoard请求的URL。这将ReviewBoard附加到JIRA,以便于访问。
-
要取消请求,请单击。
有关如何使用ReviewBoard的更多信息,请参阅 ReviewBoard文档。
提交者负责审查和整合代码更改,测试和投票候选版本,权衡设计讨论以及其他类型的项目贡献。 PMC根据对项目贡献的评估,投票决定让贡献者成为提交者。预计提交者将展示对项目和社区参与的高质量贡献的持续历史。
贡献可以通过多种方式进行。成为提交者没有单一的途径,也没有任何预期的时间表。提交功能,改进和错误修复是最常见的途径,但其他方法都得到了认可和鼓励(对于HBase作为项目和社区的健康状况可能更为重要)。潜在贡献的非详尽清单(无特定顺序):
-
更新文档以了解新的更改,最佳做法,配方和其他改进。
-
使网站保持最新。
-
执行测试并报告结果。例如,总是赞赏尺度测试和测试非标准配置。
-
维护共享的Jenkins测试环境和其他测试基础架构。
-
在执行验证后投票发布候选,即使不具有约束力。非约束性投票是非提交者的投票。
-
为邮件列表(通常在主题行中有
[DISCUSS])的讨论主题提供输入。 -
回答用户或开发人员邮件列表和Slack上的问题。
-
确保HBase社区是一个热情的社区,并且我们遵守我们的行为准则。如果您有疑虑,请提醒PMC。
-
查看其他人的工作(代码和非代码)并提供公众反馈。
-
报告找到的错误或提交新功能请求。
-
分类问题并保持JIRA的组织。这包括根据需要关闭陈旧问题,标记新问题,更新元数据和其他任务。
-
各种导师的新贡献者。
-
谈谈和写关于HBase的博客。将这些添加到网站的新闻部分。
-
提供有关HBase,Web UI,CLI,API和网站的UX反馈。
-
编写演示应用程序和脚本。
-
帮助吸引和留住多元化的社区。
-
以有利于HBase和其他项目的方式与其他项目互动。
并非每个人都能够完成此列表中的所有(甚至任何)项目。如果您想到其他贡献方式,请选择它(并将它们添加到列表中)。为了对HBase项目产生积极影响,您需要一个愉快的风度和贡献的意愿。邀请成为提交者是长期与社区稳定互动的结果,这建立了信任和认可。
鼓励新的提交者首先阅读Apache的通用提交者文档:
HBase提交者应尽可能多地尝试审查其他人提交的补丁。理想情况下,每个提交的补丁都会在几天内由提交者_审核_。如果提交者审查他们没有创作的补丁,并认为它具有足够的质量,那么他们可以提交补丁。否则,应该取消补丁,并清楚解释它被拒绝的原因。
提交的补丁列表位于 HBase Review Queue 中,该队列按上次修改时间排序。提交者应该从上到下扫描列表,寻找他们认为有资格审查并可能提交的补丁。如果您看到一个补丁,您认为其他人更有资格审核,您可以在JIRA中通过用户名提及它们。
对于非平凡的更改,需要另一个提交者在提交之前检查您的修补程序。 不允许自行提交非平凡补丁。 使用JIRA中的 Submit Patch 按钮,就像其他贡献者一样,然后在提交之前等待来自另一个提交者的+1响应。
应拒绝不符合 HowToContribute 和代码审查清单中的指南的补丁。提交者应始终对贡献者保持礼貌,并尝试指导并鼓励他们提供更好的补丁。如果提交者希望改进不可接受的补丁,那么首先应该拒绝补丁,并且应该由提交者附加新的补丁以供进一步审查。
提交者向Apache HBase GIT存储库提交补丁。
在你提交之前!
确保您的本地配置正确,尤其是您的身份和电子邮件。检查$ git config --list命令的输出并确保它是正确的。如果需要指针,请参阅设置Git 。
提交补丁时:
-
在提交消息中包含Jira问题ID以及更改的简短描述。尝试添加不仅仅是Jira标题的东西,以便有人看
git log输出不必去Jira来辨别变化是什么。确保问题ID正确,因为这会导致Jira链接到Git中的更改(使用问题的“所有”选项卡查看这些自动链接)。 -
将补丁提交到基于
master或其他预期分支的新分支。在这个分支的名称中包含JIRA ID是个好主意。查看要提交的相关目标分支,并通过执行git pull --rebase或其他类似命令确保本地分支具有所有远程更改。接下来,樱桃选择每个相关分支(例如master)的更改,并使用git push <remote-server><remote-branch>等命令将更改推送到远程分支。</remote-branch></remote-server>> 如果您没有进行所有远程更改,则推送将失败。如果推送因任何原因失败,请解决问题或寻求帮助。不要做git push --force。
在提交补丁之前,您需要确定补丁的创建方式。围绕创建补丁的方式的说明和偏好已经改变,并且将存在过渡期。
确定修补程序的创建方式
-
如果补丁的前几行看起来像电子邮件的标题,带有From,Date和Subject,则使用git format-patch创建。这是首选方法,因为您可以重用提交者的提交消息。如果提交消息不合适,您仍然可以使用提交,然后根据需要运行
git commit --amend和reword。 -
如果补丁的第一行看起来类似于以下内容,则使用git diff创建而不使用
--no-prefix。这也是可以接受的。注意文件名前面的a和b。这表明补丁不是用--no-prefix创建的。diff --git a/src/main/asciidoc/_chapters/developer.adoc b/src/main/asciidoc/_chapters/developer.adoc -
如果补丁的第一行看起来类似于以下(没有
a和b),则补丁是使用git diff --no-prefix创建的,您需要将-p0添加到下面的git apply命令中。diff --git src/main/asciidoc/_chapters/developer.adoc src/main/asciidoc/_chapters/developer.adoc
示例43.提交补丁的示例
你会注意到这些例子的一件事是有很多git pull命令。实际将任何东西写入远程存储库的唯一命令是git push,你需要确保你拥有正确的所有版本,并且在推送之前没有任何冲突。额外的git pull命令通常是多余的,但比抱歉更安全。
第一个示例显示如何应用使用git format-patch生成的补丁并将其应用于
master和branch-1分支。使用git format-patch而不是git diff而不使用
--no-prefix的指令是一个新指令。请参阅第二个示例,了解如何应用使用git diff创建的补丁,并教育创建补丁的人员。$ git checkout -b HBASE-XXXX $ git am ~/Downloads/HBASE-XXXX-v2.patch --signoff # If you are committing someone else's patch. $ git checkout master $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary or ask the submitter to do it $ git pull --rebase # Better safe than sorry $ git push origin master # Backport to branch-1 $ git checkout branch-1 $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary $ git pull --rebase # Better safe than sorry $ git push origin branch-1 $ git branch -D HBASE-XXXX此示例显示如何提交使用git diff而不使用
--no-prefix创建的修补程序。如果使用--no-prefix创建补丁,请将-p0添加到git apply命令。$ git apply ~/Downloads/HBASE-XXXX-v2.patch $ git commit -m "HBASE-XXXX Really Good Code Fix (Joe Schmo)" --author=<contributor> -a # This and next command is needed for patches created with 'git diff' $ git commit --amend --signoff $ git checkout master $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary or ask the submitter to do it $ git pull --rebase # Better safe than sorry $ git push origin master # Backport to branch-1 $ git checkout branch-1 $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary or ask the submitter to do it $ git pull --rebase # Better safe than sorry $ git push origin branch-1 $ git branch -D HBASE-XXXX -
-
将问题解决为固定的,感谢贡献者。此时始终设置“修复版本”,但仅为已提交更改的每个分支设置单个修订版本,即将在其中显示更改的分支中的最早版本。
提交消息应包含JIRA ID以及修补程序的功能描述。首选的提交消息格式为:
<jira-id> <jira-title> (<contributor-name-if-not-commit-author>)
HBASE-12345 Fix All The Things (jane@example.com)
如果贡献者使用git format-patch生成补丁,则他们的提交消息在他们的补丁中,您可以使用它,但请确保JIRA ID位于提交消息的前面,即使贡献者将其遗漏。
我们已经建立了承诺掌握的做法,然后尽可能地回到分支机构,除非
-
它正在打破compat:在这种情况下,如果它可以进入次要版本,则向后移植到branch-1和branch-2。
-
这是一个新功能:对于维护版本不适用,对于次要版本,讨论并达成共识。
当存在轻微冲突时,我们可以修复它并继续提交。生成的提交保留原始作者。当修改作者与原始提交者不同时,在提交消息的末尾添加以下内容:Amending-Author: Author <committer&apache>参见[HBase,mail#dev - 讨论的讨论修改提交时的最佳实践从主人到分店挑选]。
作为一个项目,我们努力确保每个变更都有一个JIRA,但我们并未要求任何特定工具用于评审。由于ASF在托管的git存储库和GitHub之间的集成的实现细节,PMC无法直接关闭我们的GitHub存储库上的PR。如果贡献者在GitHub上发出了拉取请求,或者因为贡献者发现比将补丁附加到JIRA更容易,或者因为审阅者更喜欢用于检查更改的UI,那么在提交中记下PR是很重要的。到主分支,以便PR保持最新。
要阅读有关GitHub“close via keyword in commit”机制的提示消息的详细信息,请参阅 GitHub文档“使用关键字关闭问题”。总之,您应该包含一个包含短语“closing #XXX”的行,其中XXX是拉取请求ID。拉取请求ID通常在主题标题末尾的灰色GitHub UI中给出。
如果提交者提交补丁,他们有责任确保它通过测试套件。如果贡献者注意他们的补丁不会破坏hbase构建和/或测试,那么这是有帮助的,但最终,不能指望贡献者知道像HBase这样的项目中发生的所有特定变幻莫测和互连。提交者应该。
在线程 HBase,邮件#dev - 通知:Git Migration In Progress(WAS⇒Re:Git Migration)中,对以下补丁流程达成了一致意见
-
首先开发并提交针对master的补丁。
-
如果可能的话,尝试在向后移动时挑选补丁。
-
如果这不起作用,请手动将修补程序提交到分支。
避免合并提交,因为它们会在git历史记录中产生问题。
参见文献的附录。
提交者应该在irc.freenode.net的#hbase会议室中进行实时讨论。但是,任何实质性讨论(与任何列表项目相关的讨论一样)都应该在Jira或开发人员列表中重新进行。
拼写错误和/或错误的语法比JIRA评论编辑导致的中断更可取:参见上的讨论Re:(HBASE-451)从HRegionInfo 中删除HTableDescriptor
为hbase-2.0.0的发布创建了一个新项目。它被称为hbase-thirdparty。该项目仅用于为主hbase项目提供流行的第三方库(如番石榴,netty和protobuf)的重定位或阴影版本。主线HBase项目依赖于从hbase-thirdparty获取的这些库的重定位版本,而不是在通常位置查找这些类。我们这样做,所以我们可以指定我们希望的任何版本。如果我们不重新定位,我们必须协调我们的版本以匹配hadoop,spark和其他项目使用的版本。
对于开发人员来说,这意味着你需要小心引用netty,guava,protobuf,gson等类。(参见hbase-thirdparty pom.xml提供的内容)。开发人员必须参考hbase-thirdparty提供的类。在实践中,这通常不是问题(虽然它可能有点痛苦)。您将不得不寻找特定类的重定位版本。您可以通过添加org.apache.hbase.thirdparty.的常规重定位前缀来找到它。例如,如果您正在寻找com.google.protobuf.Message,HBase内部使用的重新定位版本可以在org.apache.hbase.thirdparty.com.google.protobuf.Message中找到。
对于一些第三方库,比如protobuf(参见本书中的protobuf章节了解原因),你的IDE可能会给你两个选项 - com.google.protobuf. 和org.apache.hbase.thirdparty.com.google.protobuf. - 因为这两个类都在你的CLASSPATH。除非您正在进行协处理器端点开发所需的特定杂耍(再次参见上面引用的protobuf章节),否则您将始终使用着色版本。
hbase-thirdparty项目的groupid为org.apache.hbase.thirdparty。在撰写本文时,它提供了三个罐子;一个用于hbase-thirdparty-netty的人工制造,一个用于hbase-thirdparty-protobuf的protobuf,然后是一个罐子用于其他所有 - gson,番石榴 - 在hbase-thirdpaty-miscellaneous。
hbase-thirdparty工件是由HBase项目管理委员会支持下的Apache HBase项目生成的产品。发布是通过hbase dev邮件列表上的常规投票项目完成的。如果在hbase-thirdparty中出现问题,请使用hbase JIRA和邮件列表发布通知。
HBase相关Maven原型的开发始于 HBASE-14876 。有关hbase-archetypes基础结构的概述以及开发新的HBase相关Maven原型的说明,请参阅hbase/hbase-archetypes/README.md。