| Table of Contents |
|---|
Links
Configure git for http only clients - as in developers behind a firewall proxy that blocks SSH (in this case use git push origin HEAD:refs/for/master instead of git review - Configuring Gerrit
Prerequisite: Set Up
The actions described in this section depend on having the requisite set of tools and settings on your development machine. See Setting Up Your Development Environment.
Note: replace openecomp.org with onap.org in all screen captures - reason: https will authenticate against the actual onap.org domain but ssh will redirect from either.
Reference: Gerrit Code Review for Git
ONAP uses Gerrit to automate the process of reviewing all code changes before they are committed to the Git repository. Here is a tutorial and reference on using Gerrit: https://gerrit.onap.org/r/Documentation/index.html.
Using the Command Line to Clone the Repository
- Move to the folder at the root of your development directory. For example:
cd C:\Users\<user>\Documents\work
- Add a remote pointer to the Gerrit server that hosts your repository using either SSH or HTTPS. (Note: <REPONAME>s are given in various Development Guides.
Using SSH:git remote add origin ssh://USERNAME@gerrit.openecomponap.org:29418/<REPONAME>
Using HTTPS:
With HTTPS, first you will need the Gerrit HTTP-generated password for each HTTPS operation with Gerrit/Git/Gerrit.
git remote add originhttps://USERNAME@gerrit.openecomponap.org/r/a/<REPONAME>
- Now clone the remote repository. Since we clone in the current folder, it will create a subfolder with the remote copy.
Using SSH:git clone ssh://USERNAME@gerrit.openecomponap.org:29418/<REPONAME>
Using HTTPS:
With HTTPS, first you will need the Gerrit HTTP-generated password for each HTTPS operation with Gerrit/Git/Gerrit.
git clone https://USERNAME@gerrit.openecomponap.org/r/a/<REPONAME>
...
Using IntelliJ to Clone From, and Commit
...
To, Gerrit/Git
Visit https://gerrit.openecomponap.org and log in, using your Linux Foundation identity. Here, you will be able to view the names of Projects to which you have access.
On top of the project listing, the web site provides you the command to clone the whole project, such as:
The project can be downloaded in either of two ways, via HTTP url or SSH url.
IntelliJ and SSH URL (Recommended)
To download the project with ssh urlusing an SSH URL, you need to add the ssh have already added your SSH key into the Linux Foundation Gerrit website.
In the Settings window, select SSH Public Keys. Put your public key of your machine into the window and click Add.
The steps to create the SSH Key could be found in the following page: Having added your key, visit https://helpgerrit.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
Click ssh under the Linux Foundation Project page, it will display the url to use to clone the project.
Then open your IntelliJ, click File -> Settings -> Version Control -> Gerrit, enter the URL for the Linux Foundation Gerrit website, your Linux Foundation username and password and click OK. To test whether the connection is good, you can also click the Test button before clicking OK.
onap.org/r/#/admin/projects/ and select the project you are working on. The Gerrit site will show the full URL for the project:
Next, within IntelliJ, select Then open File -> New -> Project from Version Control -> Git to open open the Clone Repository window. Enter the ssh url you have found above, chose your Parent Directory and Directory Name and click SSH URL from above, including the project name (mso in this example), and chose your local Parent Directory. IntelliJ will fill in the Directory Name for you. Click Clone to clone the project.
For the first downloading, a OpenSSH window a window will appear to authenticate the host. Enter yes in the command location and click OK to progressClick Yes to continue.
IntelliJ and HTTP URL (Alternate Method)
Open IntelliJ and click File -> Settings -> Version Control -> Gerrit. In the resulting dialog box, enter the Gerrit URL as shown above, along with your Linux Foundation username and password. To test whether the connection is good, you can click the Test button:
| Info | ||
|---|---|---|
| ||
The URL must use https:, not http:. |
Once you have entered this information, click OK:
Then open File -> New -> Project from Version Control -> Git to open Clone Repository window. Enter the http url you have found above, but with https not with http, chose your local Parent Directory and Directory Name and click Clone to clone the project.
A window will pop up to input the user name and password. The user name is the username of your Linux Foundation account, and the password is the Gerrit HTTPS password generated during setup.
Commit Changes Locally
Once you have made changes in the code, before you push the changes, you should commit the code locally.
To do that, go to the Version Control window, under Local Changes, right click the changed files and click Commit Changes....
Pushing changes for review using a command line
In the Commit Changes window, enter the Commit Message, select Sign-off commit option and click Commit button.
Pushing Changes for Review Using a Command Line (optional)
Here are the Git commands to
...
add some files and
...
make a commit with an associated message:
git
...
add
...
somefiles
git
...
commit
...
-m
...
"My
...
first
...
Awesome
...
commit"
...
Note that this is just an example and the commit message should be
...
more explicit than that.
Now that everything is ready, you can sign off your commit
...
:
git
...
review
...
-s
if asked for a remote gerrit run
git config --global gitreview.remote origin
You may be prompted for your Linux Foundation account password.
...
To verify that the commit
...
worked, this command will show you the commit message and the sign off entry:
...
| Info | ||
|---|---|---|
| ||
You can automatically add the signature for all your commits by setting the git configuration: |
...
|
Verify you are setup with the correct account
vi ~/.gitconfig [gitreview] username = youruser |
|---|
Eventually, we can push the change to the gerrit server:
git
...
review
Committer/Contributor Actions
The code should now appear in the gerrit web interface, it needs a committer to . A contributor or committer can review it with a -1/0/+1 and mark it as verified with test results if available. It needs a committer to approve it with a +2 rating, and to also move the verifed flag to +1, to do so, the committer can open the gerrit UI and click on the open review list
. The committer does this by visiting the gerrit.onap.org site and logging in.
The committer may take any of several actions, such as clicking on the "Reply" button, adding reviewers, adding Then click on the Reply button, you can also add reviewers for their inputs, add a review comment, and move moving the flags to +2 and +1
Once a committer/contributor approves it, the code can be merged to the master branch
If issues are found, both contributors and committers can amend the review (use the top-left download link on the review screen to get the direct clone commands that would download the reviewed code in a local repository)
Similarly to the above steps, do the needed modifications, and push the changes (again after signing them) using git review
Note that you can also work on local branch, gerrit will automatically use your local branch name as a Topic for the review, allowing you to share branches between team members
More details on how to use gerrit : https://gerrit.openecomp.org/r/Documentation/index.html
Commit Changes
Once you have made changed in the code, before push the changes, you should commit the code locally first.
To do that, go to the Version Control window, under Local Changes, right click the changed files and click Commit Changes....
In the Commit Changes window, enter the Commit Message, select Sign-off commit option and click Commit button.
Then go to the Terminal window, use command apt-get install git-review to install git-review plugin in the machine, if not already installed.
...
If your address is not present or not the same as the one defined in Linux Foundation account, enter command git config --global user.email "jondoe@somewhere.com".
Then enter command git commit -as s --amend to show the commit message and the sign off entry, as shown below. Make sure the email address is the exactly the same as the email you used in the Linux Foundation account. If not, update the address.
...
Go to Gerrit window and refresh, the committed changes will be shown in the window. Right click the commit, you can find the tab to Add Reviewers for reviewing or Abandon the changes if you don't want it any more.
If you have been selected as the reviewer of the changes. You can right click the corresponding commit and click Review, Code-Review to give your score and comments for the change.
JBL Templates for on-demand Gerrit recheck or remerge
https://lists.onap.org/pipermail/onap-discuss/2018-January/007781.html
https://lists.onap.org/g/onap-discuss/message/7773?p=,,,20,0,0,0::relevance,,recheck,20,2,0,22459587
Thanks Alexis de Talhouët - you can type "recheck" or "remerge" in the comment to kick in another JobBuilder run if required
A rebase will also kick in a build
see the ci-management ONAP project
https://github.com/onap/ci-management/blob/master/jjb/global-macros.yaml#L343
Failed Commit / Resubmit
If issues are found, both contributors and committers can amend the review (use the top-left download link on the review screen to get the direct clone commands that would download the reviewed code in a local repository)
Similarly to the above steps, do the needed modifications, and push the changes (again after signing them) using git review
Note that you can also work on local branch, Gerrit will automatically use your local branch name as a Topic for the review, allowing you to share branches between team members.
Example Session
ssh-add onap_rsa git clone ssh://username@gerrit.openecomp.org:29418/portal or via https (note openecomp.org now redirects to onap.org) obrienbiometrics:onap4 michaelobrien$ git clone https://gerrit.onap.org/r/a/mso Cloning into 'mso'... Username for 'https://gerrit.onap.org': michaelobrien Password for 'https://michaelobrien@gerrit.onap.org': remote: Total 4596 (delta 0), reused 4596 (delta 0) Receiving objects: 100% (4596/4596), 2.94 MiB | 1.68 MiB/s, done. Resolving deltas: 100% (1985/1985), done. |
|---|
Magic Words
Sometimes automatic verification/build/deploy doesn't happen as expected. In that case, use the gerrit Reply feature to insert the magic word into the message body.
| Action Desired | Magic Words | Result | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| trigger the verify job | recheck | re-runs the Jenkins Job Builder (JJB) on an unmerged set of code | |||||||||||||
| trigger check of self release | recheck|reverify | will trigger the "{project-name}-release-verify-{stream}" job. Will make sure the release file contains the needed information and that the candidate exists. (NOTE: possible confusion here over syntax...is that bar (|) to be included or can you use either of these words in the Reply?) Ref: Self Releases Workflow (Nexus2) | |||||||||||||
| trigger the helm verify job | verify-helm | re-runs the JJB verify-helm job used in the OOM project | |||||||||||||
| trigger the merge build Jenkin job | remerge | re-runs the JJB deploy on a merged set of code | |||||||||||||
| trigger self release of artifact | remerge | runs the "{project-name}-release-merge-{stream}" job to push the release and tag the repo. Ref: Self Releases Workflow (Nexus2) | |||||||||||||
| trigger daily release job | please release | re-runs the JJB daily release build | |||||||||||||
| stage-release | re-runs the JJB daily maven-stage build (replaces "please release") | ||||||||||||||
| trigger CLM jobs | run-clm | The CLM jobs are still scheduled to run every Saturday, this feature can be useful for debugging on demand. Commenting "run-clm" in a gerrit that is not merged, will not trigger the CLM job based on that revision but will trigger the job based on the tip of the branch. This job is designed to always run on the latest tip of the branch to avoid inconsistencies on the reports. Source: Configuring Gerrit | |||||||||||||
| trigger Sonar job | run-sonar | this is used to follow up closely on code coverage progress. | |||||||||||||
| rebase | N/A | There is no magic word for this desired action. Instead, hit the button in the review page. | |||||||||||||
trigger OOM CD deployment / healthcheck for component under review | run-helm-deploy | 20181122 - in progress
will run an OOM deploy of the component and any dependent component on request (before a merge) for example if the current helm-verify job is +1 - a full deploy of the component via --set <pod>.enabled=true will be done, healthcheck run and reported back as a +1 if we get a pass for the pod Example of what the jjb job will run when deploying pomba - requires dmaap to function.
| |||||||||||||
| Re-run CI Deployment test | oom_redeploy | Re-runs the remote CI oom deployment job in Orange Lab | |||||||||||||
| Create Jenkins job in Sandbox | Posting this |
Links
ONAP Development — Should we put the above section in a sub section