Gerrit Archives - scmGalaxy

Best Branching and Merging strategies in Gerrit

scmgalaxy K — Wed, 22 Aug 2018 14:09:36 +0000

Best Branching and Merging strategies in Gerrit

Step 1 – First Lets read this article about Best Branching and Merging strategies in git

Best Branching and Merging strategies in git

Step 2 – Now Lets learn the Gerrit Merge Types
https://nofluffjuststuff.com/magazine/2016/04/understanding_and_applying_gerrit_part_3_gerrit_submit_types_and_git_review

Step 3 – Time to Learn the Types of Submit in Gerrit
https://gerrit-review.googlesource.com/Documentation/project-configuration.html

Step 4 – Finally, You must read the recommendations below
https://hyperledger-fabric.readthedocs.io/en/release-1.2/Gerrit/best-practices.html

The post Best Branching and Merging strategies in Gerrit appeared first on scmGalaxy.

How to revert the changes once its submitted in Gerrit

scmgalaxy K — Wed, 22 Aug 2018 13:10:23 +0000

How to revert the changes once its submitted in Gerrit

The Revert button is available if the change has been submitted. This Reverts the change via creating a new one. When the Revert button is pressed, a panel will appear to allow the user to enter a commit message for the reverting change.

Once a revert change is created, the original author and any reviewers of the original change are added as reviewers and a message is posted to the original change linking to the revert.

However, patchsets can not be reverted. so first you have to checkout one of the previous patchset. you can get the command from Gerrit review board at each patchset download panel. After checking it out amend it to generate new commit hash then pushed again as a new patchset.

If I have multiple patch set versions for one change in Gerrit, You can only submit the latest patch set version. The design assumes that the most recent patch set is the one developers will review and test, and as such older patch sets can not be submitted.

Good Read
http://www.saros-project.org/node/155

The post How to revert the changes once its submitted in Gerrit appeared first on scmGalaxy.

What is a Change and Patch set in Gerrit?

scmgalaxy K — Wed, 22 Aug 2018 12:57:45 +0000

Here is the short and quick description of Gerrit key teminology.

Change

Every time you push a commit with a new Change-Id Gerrit allocates a new change. Every change has a unique Change-Id and a Change Number. The change contains a number of patch sets, comments on the patch sets and a code review rating (+2, +1, 0, -1, -2). Each change has a dedicated page that shows information about it called individual change page. This includes dependencies between different changes, patch sets and the review comments.

Submit

Once a change has received a +2 in the Code Review and no negative voting in the other categories the last patchset can be submitted. This means Gerrit will now try to cherry-pick your patch set and mark the change as merged.

Patch set

If you want to modify your change, you don’t have to push a new change to Gerrit but only a new patch set . Imagine a patch sets as different versions or revisions of a change. Each patch set can receive inline comments. Gerrit uses the Change-Id of a commit message to identify patch sets of a change. This is why all patch sets of a change have the same Change-Id.

To create a new Patch when new changes are submitted
Step 1: Install commit-msg hooks for gerrit

$ scp -p -P 29418 localhost:hooks/commit-msg .git/hooks/

Step 2: Create normal commit and push (for Patchset1)

for example:

git add Server.java
git commit -m "server added"
git push origin HEAD:refs/for/master

Step 3: After doing some changes to Server.java

Finally to create new Patchset (Patchset 2)

git add Server.java
git commit --amend
git push origin HEAD:refs/for/master
Repeat step 3 for further Patches

Understanding the Patch set in Git perspective

Git is a very advanced distributed source code control system. Maintaining patch sets (often called a topic branch) in Git. Git includes a rebase capability that is very useful for a number of different operations related to maintaining a branch of code including moving a branch forward, moving a branch around on an upstream branch to look for breakage, and merging changesets to create patch files.

Git: How to create and apply patches

Creating a patch

Make your changes and commit them.
Run $ git format-patch COMMIT_REFERENCE #to convert all commits since the referenced commit (not including it) into patch files.
$ git format-patch HEAD~~

This will create 2 files, one for each commit since HEAD~~, like these:
0001-make-stuff-more-awesome.patch
0002-allow-users-to-be-locked.patch

Applying patches
You can use git apply some.patch to have the changes from the .patch file applied to your current working directory. They will be unstaged and need to be committed by you.

To apply a patch as a commit (with its commit message), use git am some.patch. \
For all patches to be applied, simply run:
$ git am *.patch

Note that in some previous version you could pass the latest patch filename of a list of patches to apply all previous patches as wel
$ git am 0002-allow-users-to-be-locked.patch # May no longer work for you

You then have the 2 unpushed commits from the patch file created earlier.

The post What is a Change and Patch set in Gerrit? appeared first on scmGalaxy.

How to replace Changes after the Gerrit review without changing the commit id?

scmgalaxy K — Wed, 22 Aug 2018 12:17:20 +0000

How to replace Changes after the Gerrit review without changing the commit id?

One of the main benefits of code review is the ability to receive and incorporate feedback from other developers without changing the commit-id and review id. With Gerrit, you incorporate these changes by amending the commit. Gerrit uses the CHange-Id to ensure that each iteration of the commit are stored together as patchsets.

The process of modify same commit and commit message on gerrit after patchset creation is pretty straight forward.

Step 1 – Do the required modification in the code based on the review.

Step 2 – Add files using git add commands.

$ git add filename

Step 3 – Command to update/amend the most recent commit.

$ git commit --amend

When amending a commit with git commit –amend, leave the Change-Id line unmodified in the commit message. This will allow Gerrit to automatically update the change with the amended commit.

Step 4 – Gerrit updates the commit under review with your latest changes.

$ git push origin HEAD:refs/for/master
$ git push origin HEAD:refs/for/[BRANCH_NAME]

The post How to replace Changes after the Gerrit review without changing the commit id? appeared first on scmGalaxy.

How to compile and build Gerrit Plugins?

scmgalaxy K — Sun, 19 Aug 2018 20:09:20 +0000

To build Gerrit Plugins from source, you need:

A Linux or macOS system (Windows is not supported at this time)

zip, unzip, wget

$yum install zip -y
$ yum install unzip -y
$ yum install wget -y
$ yum install git -y

Python 2 or 3
This is installed in each RHEL 7 and Ubunutu server by defaul.

Node.js

curl --silent --location https://rpm.nodesource.com/setup_8.x | sudo bash -
OR
curl --silent --location https://rpm.nodesource.com/setup_10.x | sudo bash -
sudo yum -y install nodejs

Bazel

## RHEL/CentOS 7 64-Bit ##
$ wget https://copr.fedorainfracloud.org/coprs/vbatts/bazel/repo/epel-7/vbatts-bazel-epel-7.repo
$ cp vbatts-bazel-epel-7.repo /etc/yum.repos.d/
$ yum install -y bazel

How to Installing Bazel on Ubuntu?
https://docs.bazel.build/versions/master/install-ubuntu.html

Maven

$ cd /opt
$ wget http://www-us.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.zip
$ unzip apache-maven-3.5.4-bin.zip
$ mv apache-maven-3.5.4 maven
$ export PATH=$PATH:/op/maven/bin

gcc

$ sudo yum install gcc-c++ make

Now, Bazel in tree driven means it can only be built from within Gerrit tree. Clone or link the plugin into gerrit/plugins directory:

# First become a non-root user

A JDK for Java 8

$ cd
$ wget -c --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz
$ tar -xvf jdk-8u181-linux-x64.tar.gz
$ export JAVA_HOME=/home/ec2-user/jdk1.8.0_181
$ java -version

Follow for Gerrit.war

$ git clone --recursive https://gerrit.googlesource.com/gerrit
$ cd gerrit 
$ bazel build release

Follow for plugins such as its-jira

$ cd plugins
$ git clone https://gerrit.googlesource.com/plugins/its-jira
$ git clone https://gerrit.googlesource.com/plugins/its-base
$ bazel build plugins/its-jira

The output can be normally found in the following directory:

bazel-genfiles/plugins/its-jira/its-jira.jar

# Some plugins describe their build process in src/main/resources/Documentation/build.md file. It may worth checking.

# Some plugins cane be build using maven as well

Reference

https://gerrit-review.googlesource.com/Documentation/dev-bazel.html
https://gerrit.googlesource.com/gerrit/
https://gerrit-review.googlesource.com/Documentation/cmd-plugin-install.html
https://gerrit-review.googlesource.com/Documentation/dev-build-plugins.html

The post How to compile and build Gerrit Plugins? appeared first on scmGalaxy.

What is “Install Verified label” in Gerrit?

scmgalaxy K — Sun, 19 Aug 2018 19:45:24 +0000

What is “Install Verified label” in Gerrit?

The Verified label was originally invented by the Android Open Source Project to mean ‘compiles, passes basic unit tests’. Some CI tools expect to use the Verified label to vote on a change after running.

During site initialization the administrator may have chosen to configure the default Verified label for all projects. In case it is desired to configure it at a later time, administrators can do this by adding the following to project.config in All-Projects:

[label “Verified”]
function = MaxWithBlock
value = -1 Fails
value = 0 No score
value = +1 Verified
copyAllScoresIfNoCodeChange = true
The range of values is:

-1 Fails
Tried to compile, but got a compile error, or tried to run tests, but one or more tests did not pass.
Any -1 blocks submit.

0 No score
Didn’t try to perform the verification tasks.

+1 Verified
Compiled (and ran tests) successfully.
Any +1 enables submit.

For a change to be submittable, the change must have a +1 Verified in this label, and no -1 Fails. Thus, -1 Fails can block a submit, while +1 Verified enables a submit.

Additional values could also be added to this label, to allow it to behave more like Code-Review (below). Add -2 and +2 entries to the label.Verified.value fields in project.config to get the same behavior.

As an example, the popular gerrit-trigger plugin for Jenkins/Hudson can set labels at:

The start of a build
A successful build
An unstable build (tests fails)
A failed build

Usually the range chosen for this verdict is the Verified label. Depending on the size of your project and discipline of involved developers you might want to limit access right to the +1 Verified label to the CI system only. That way it’s guaranteed that submitted commits always get built and pass tests successfully.

If the build doesn’t complete successfully the CI system can set the Verified label to -1. However that means that a failed build will block submit of the change even if someone else sets Verified +1. Depending on the project and how much the CI system can be trusted for accurate results, a blocking label might not be feasible. A recommended alternative is to set the label Code-review to -1 instead, as it isn’t a blocking label but still shows a red label in the Gerrit UI. Optionally, to enable the possibility to deliver different results (build error vs unstable for instance), it’s also possible to set Code-review +1 as well.

If pushing new changes is granted, it’s possible to automate cherry-pick of submitted changes for upload to other branches under certain conditions. This is probably not the first step of what a project wants to automate however, and so the push right can be found under the optional section.

Suggested access rights to grant, that won’t block changes:
Read on ‘refs/heads/*’ and ‘refs/tags/*’
Label: Code-Review with range ‘-1’ to ‘0’ for ‘refs/heads/*’
Label: Verified with range ‘0’ to ‘+1’ for ‘refs/heads/*’

Optional access rights to grant:
Label: Code-Review with range ‘-1’ to ‘+1’ for ‘refs/heads/*’
Push to ‘refs/for/refs/heads/*’

Reference
https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_Verified
https://gerrit-review.googlesource.com/Documentation/access-control.html#examples_cisystem
https://groups.google.com/forum/#!topic/repo-discuss/FdN29piSmEQ

The post What is “Install Verified label” in Gerrit? appeared first on scmGalaxy.

What is Enable signed push support in Gerrit?

scmgalaxy K — Sun, 19 Aug 2018 19:43:14 +0000

This options Defaults to false.

This ensure When a client pushes with git push –signed, this ensures that the push certificate is valid and signed with a valid public key stored in the refs/meta/gpg-keys branch of All-Users.

If true, server-side signed push validation is enabled.

Config in gerrit.config – receive.enableSignedPush

The post What is Enable signed push support in Gerrit? appeared first on scmGalaxy.

Importannce of Canonical web url in Gerrit

scmgalaxy K — Sun, 19 Aug 2018 19:40:44 +0000

The canonical web url must be set. Optional base URL for repositories available over the anonymous git protocol. For example, set this to git://mirror.example.com/base/ to have Gerrit display patch set download URLs in the UI. Gerrit automatically appends the project name onto the end of the URL.

By default unset, as the git daemon must be configured externally by the system administrator, and might not even be running on the same host as Gerrit.

The post Importannce of Canonical web url in Gerrit appeared first on scmGalaxy.

Authentication Types in Gerrit explained!

scmgalaxy K — Sun, 19 Aug 2018 19:38:36 +0000

Authentication Types in Gerrit explained!

Type of user authentication employed by Gerrit. The supported values are:

By default, OpenID

OpenID
The default setting. Gerrit uses any valid OpenID provider chosen by the end-user. For more information see openid.net.
OpenID_SSO
Supports OpenID from a single provider. There is no registration link, and the “Sign In” link sends the user directly to the provider’s SSO entry point.
HTTP
Gerrit relies upon data presented in the HTTP request. This includes HTTP basic authentication, or some types of commercial single-sign-on solutions. With this setting enabled the authentication must take place in the web server or servlet container, and not from within Gerrit.
HTTP_LDAP
Exactly like HTTP (above), but additionally Gerrit pre-populates a user’s full name and email address based on information obtained from the user’s account object in LDAP. The user’s group membership is also pulled from LDAP, making any LDAP groups that a user is a member of available as groups in Gerrit.
CLIENT_SSL_CERT_LDAP
This authentication type is actually kind of SSO. Gerrit will configure Jetty’s SSL channel to request the client’s SSL certificate. For this authentication to work a Gerrit administrator has to import the root certificate of the trust chain used to issue the client’s certificate into the /etc/keystore. After the authentication is done Gerrit will obtain basic user registration (name and email) from LDAP, and some group memberships. Therefore, the “_LDAP” suffix in the name of this authentication type. This authentication type can only be used under hosted daemon mode, and the httpd.listenUrl must use https:// as the protocol. Optionally, certificate revocation list file can be used at /etc/crl.pem. For details, see httpd.sslCrl.
LDAP
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
The actual username used in the LDAP simple bind request is the account’s full DN, which is discovered by first querying the directory using either an anonymous request, or the configured ldap.username identity. Gerrit can also use kerberos if ldap.authentication is set to GSSAPI.
LDAP_BIND
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
Unlike LDAP above, the username used to perform the LDAP simple bind request is the exact string supplied in the dialog by the user. The configured ldap.username identity is not used to obtain account information.
OAUTH
OAuth is a protocol that lets external apps request authorization to private details in a user’s account without getting their password. This is preferred over Basic Authentication because tokens can be limited to specific types of data, and can be revoked by users at any time.
Site owners have to register their application before getting started. Note that provider specific plugins must be used with this authentication scheme.
DEVELOPMENT_BECOME_ANY_ACCOUNT
DO NOT USE. Only for use in a development environment.
When this is the configured authentication method a hyperlink titled Become appears in the top right corner of the page, taking the user to a form where they can enter the username of any existing user account, and immediately login as that account, without any authentication taking place. This form of authentication is only useful for the GWT hosted mode shell, where OpenID authentication redirects might be risky to the developer’s host computer, and HTTP authentication is not possible.

Reference
https://dev.vaadin.com/review/Documentation/config-gerrit.html#auth

The post Authentication Types in Gerrit explained! appeared first on scmGalaxy.

How to backup and restore Gerrit server?

scmgalaxy K — Sun, 19 Aug 2018 19:34:09 +0000

How to backup and restore gerrit server?

There are 3 coponent which should be backed up in gerrit

Repository – According to me best way to backup the repository is to setup a replication with other gerrit hosting tools using gerrit replication plugins. The steps can be find as below;
Gerrit Database
Depends on the database, you should take the database backup. It can be H2 or mysql….
Gerrit Config
Rysnc is the best tools to take the entire gerrit site backup.

How to replicate Gerrit repository using replication plugins?

Step 1- Setup Gerrit Server
http://www.devopsschool.com/tutorial/gerrit/gerrit-install-and-configuration.html

Step 2 – Create a Project in Gerrit

Step 3 – Setup a Developement Machine
git clone http://admin@35.154.81.167:8080/a/prj1 && (cd prj1 && curl -kLo `git rev-parse –git-dir`/hooks/commit-msg http://admin@35.154.81.167:8080/tools/hooks/commit-msg; chmod +x `git rev-parse –git-dir`/hooks/commit-msg)

Step 4: Sample Commits to be done
> touch file1.txt;git add .;git commit -m”adding first version”

Step 5: Sample push and submit it
> git push origin HEAD:refs/for/master

Step 6: create it $site_path/etc/replication.config

Content of the files is –
[remote “github”]
url = git@github.com:scmgalaxy/${name}.git

Within each URL value the magic placeholder `${name}` is replaced with the Gerrit project name.

Step 7: Generate a public/private key

> ssh-keygen -t rsa

Step 8: create a “config” under /root/.ssh

Host github.com
User git
IdentityFile /root/.ssh/id_rsa
StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Step 9: Update the public key to github

Step 10: Create a repo in Github.com with same name.

The post How to backup and restore Gerrit server? appeared first on scmGalaxy.

How Gerrit Works?

scmgalaxy K — Sun, 19 Aug 2018 19:14:00 +0000

When Gerrit is configured as the central source repository, all code changes are sent to Pending Changes for others to review and discuss. When enough reviewers have approved a code change, you can submit the change to the code base.

In addition to the store of Pending Changes, Gerrit captures notes and comments made about each change. This enables you to review changes at your convenience or when a conversation about a change can’t happen in person. In addition, notes and comments provide a history of each change (what was changed and why and who reviewed the change).

Gerrit project is a workspace consisting of the following elements:

Git repository: It is used to store the merged code base and the changes under review that have not being merged yet. Gerrit has the limitation of a single repository per project. There can also be projects without any code repository associated at all (that is, Security-only projects)
Changes references under review: Git commit-id (expressed as SHA-1 Hexadecimal alphanumeric string) stored in the Gerrit DB and pointing to the corresponding changes stored in the Git repository. A Gerrit change is a Git commit object uploaded for review and associated to its comments and scores. It is stored in the project’s Git repository but it is not visible/accessible from the normal Git graph of commits, even it does start from a point on the commits graph.
Access Control Lists (ACLs): It contains the list of roles defined for the Gerrit project and the associated access permissions to the Git repository branches.
Prolog rules: It is the set of rules that govern the Code Review process for the project. 0 Additional metadata: All the extra settings such as description, merge strategy, contributor agreements, and accessory metadata needed in order to manage the project.

We have to make and review a change through these stages in Gerrit:

Making the change.
Creating the review.
Reviewing the change.
Reworking the change.
Verifying the change.
Submitting the change.

The post How Gerrit Works? appeared first on scmGalaxy.

Gerrit Archives - scmGalaxy

Top 50 Gerrit Interview Questions with Answers

1. What is Gerrit?

Answer: A

2. Which version control system does Gerrit use?

Answer: A

3. What is the purpose of Gerrit?

Answer: A

4. Can Gerrit be used with multiple version control systems?

Answer: B

5. What is a patch set in Gerrit?

Answer: A

6. What is a change request in Gerrit?

Answer: C

7. What is the Gerrit workflow?

Answer: A

8. What is the role of a Gerrit reviewer?

Answer: A

9. What is a Gerrit bot?

Answer: B

10. Which programming languages does Gerrit support?

Answer: A

11. What is the difference between a reviewer and an approver in Gerrit?

Answer: A

12. What is a topic branch in Gerrit?

Answer: A

13. Can Gerrit be used for non-software development projects?

Answer: A

14. What is the Gerrit Code Review plugin for Eclipse used for?

Answer: A

15. What is the Gerrit REST API used for?

Answer: A

16. What is the Gerrit configuration file?

Answer: A

17. What is the Gerrit Dashboard?

Answer: A

18. What is the difference between a Gerrit project and a Git repository?

Answer: A

19. What are the benefits of using Gerrit for code review?

Answer: A

20. How does Gerrit handle conflicts when merging code changes?

Answer: A

21. What is the Gerrit plugin architecture?

Answer: A

22. What is the Gerrit hooks mechanism used for?

Answer: A

23. What is a Gerrit label?

Answer: A

24. What is a Gerrit change ID?

Answer: A

25. What is the Gerrit Code Review plugin for Jenkins used for?

Answer: A

26. What is the Gerrit User Interface written in?

Answer: A

27. What is the Gerrit replication mechanism used for?

Answer: A

28. What is the Gerrit Project Owner role?

Answer: A

29. What is a Gerrit group?

Answer: A

30. What is the Gerrit Commit Message Hook used for?

Answer: A

31. What is the Gerrit Verification mechanism used for?

Answer: A

32. What is the Gerrit Code Review plugin for Visual Studio used for?

Answer: A

33. What is the Gerrit Code Review plugin for IntelliJ IDEA used for?

Answer: A

34. What is a Gerrit topic?

Answer: A

35. What is a Gerrit Change-Id label?

Answer: A

36. What is the Gerrit REST API authentication mechanism?

Answer: C

37. What is the Gitweb browser included with Gerrit used for?

Answer: A

38. What is Gerrit’s server-side hook mechanism used for?

Answer: A

39. What is a Gerrit change message?

Answer: A