Links

SDN-C Development Environment Setup#CDevelopmentEnvironmentSetup-Fixnochange-idHowtoFixaCommitwhichDoesNothaveaChange-Id

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

  1. Move to the folder at the root of your development directory. For example:
    cd C:\Users\<user>\Documents\work
     
  2. 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.onap.org:29418/<REPONAME>

    Using HTTPS:
    With HTTPS, first you will need the Gerrit HTTP-generated password for each HTTPS operation with Gerrit/Git.

    git remote add origin     https://USERNAME@gerrit.onap.org/r/a/<REPONAME>
     
  3. 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.onap.org:29418/<REPONAME>

    Using HTTPS:
    With HTTPS, first you will need the Gerrit HTTP-generated password for each HTTPS operation with Gerrit/Git.

    git clone https://USERNAME@gerrit.onap.org/r/a/<REPONAME>

Using IntelliJ to Clone From, and Commit To, Gerrit/Git

Visit https://gerrit.onap.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 using an SSH URL, you need to have already added your SSH key into the Gerrit website.

Having added your key, visit https://gerrit.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 File -> New -> Project from Version Control -> Git to open the Clone Repository window. Enter the 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 window will appear to authenticate the host.Click 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:

https: Required

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....


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:

See the exact commit message format at Commit Messages

git commit -s --amend


Automatic signature mode

You can automatically add the signature for all your commits by setting the git configuration:

git config --global format.signoff true

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. 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. 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 a review comment, and moving the flags to +2 and +1


Once a committer/contributor approves it, the code can be merged to the master branch.

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.


Once installed, under root location of the project enter command git config --list, make sure the email address listed is exactly the same as the one you used in your Linux Foundation account.


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 -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.


Then enter command git review to upload the changed code into the Linux Foundation for reviewing.


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 DesiredMagic WordsResult
trigger the verify job recheck re-runs the Jenkins Job Builder (JJB) on an unmerged set of code
trigger check of self releaserecheck|reverifywill 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 jobverify-helmre-runs the JJB verify-helm job used in the OOM project
trigger the merge build Jenkin jobremergere-runs the JJB deploy on a merged set of code
trigger self release of artifactremergeruns the "{project-name}-release-merge-{stream}" job to push the release and tag the repo.  Ref: Self Releases Workflow (Nexus2)
trigger daily release jobplease releasere-runs the JJB daily release build

stage-releasere-runs the JJB daily maven-stage build (replaces "please release")
trigger CLM jobsrun-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 jobrun-sonarthis is used to follow up closely on code coverage progress.
rebaseN/AThere 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

TSC-25 - Getting issue details... STATUS

meetings https://lists.onap.org/g/onap-discuss/topic/cd_task_force_tsc_25_meetings/29001640?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,29001640

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.

sudo helm deploy onap local/onap --namespace onap -f onap/resources/environments/disable-allcharts.yaml --set pomba.enabled=true --set robot.enabled=true --set dmaap.enabled=true
Re-run CI Deployment testoom_redeployRe-runs the remote CI oom deployment job in Orange Lab
Create Jenkins job in Sandboxjjb-deploy <pattern>

Posting this on a ci-management change creates jobs matching the pattern (for example "myproject-*") to the Jenkins sandbox, https://jenkins.onap.org/sandbox/.

See https://docs.releng.linuxfoundation.org/en/latest/jenkins-sandbox.html.

Links

ONAP Development


27 Comments

  1. Mike Hansen

    In intellij, I had to use http for the Gerrit setup, and then for the Git Clone, as opposed to https. When I tried with https, it never accepts either my onap, or my generated http password.

  2. Shashank Kumar Shankar

    I tried setting up the environment as suggested in this page using the 'IntelliJ and HTTP URL (Alternate Method)'. I ran into issues of Maven dependency resolving and authentication. So I did the following things to solve them:

  3. Michael O'Brien

    Had the same not authenticated issue with https cloning (ssh works fine) - turned out to just need a domain change to onap.org - thanks Shashank

    DOC-5 - Getting issue details... STATUS

    looks like a dig of both openecomp.org and onap.org point to the same IP

    openecomp.org. 10800 IN A 50.56.49.117

  4. Tian Lee

    I successfully cloned an ONAP repo using authenticated http.

    However, when I tried to setup the repo for git review by running:

     git review -s

    I got the following error:

        git_review.cmd.GitReviewException: Could not connect to gerrit at ssh://tianl@gerrit.onap.org:29418/aai/model-loader

    It appears that git review is trying to connect via SSH, but SSH is blocked by my proxy. Is it possible to configure git review to connect using HTTP?

    1. Skip Wonnell

      Try creating a remote named "gerrit" that points to http:

      git remote add gerrit https://gerrit.onap.org/r/p/<REPONAME>.git


      1. Tian Lee

        Thanks Skip Wonnell, I figured this out eventually.

        However, another solution is to configure gitreview to use "origin" as its origin by setting the following:

        $ git config --global gitreview.remote origin

  5. Mor Dabastany

    Following Tian's request, would we have any way to review via https? it's blocking us from pushing changes for review..

  6. Pamela Dragosh

    FYI - the commit should not have the JIRA in the summary, but instead in the external references section. See Commit Messages for an example.

    1. Michael O'Brien

      I agree, I'll do a test commit without the JIRA in the title.

      Currently though adding the JIRA in the title links the JIRA to the review - and also launches the JIRA

      See the merge fix for AAI today in  AAI-134

      https://gerrit.onap.org/r/#/c/6749/

      click the link in gerritt

      [AAI-134] Removed duplicate invStatus

      If linking still occurs - then we don't need the commit comment link

      I'll try in 

      OOM-5 - Getting issue details... STATUS

      /michael

      1. Pamela Dragosh

        Yeah the linking has been inconsistent when not using the summary.


        Andrew has been helping me and has told me these guidelines:

        1) Does the author = the person uploading and do they have the name and

        address correctly registered


        2) Is the subject line <= 50 characters


        3) Are < 33% of the body lines <= 72 characters


        4) Is there a JIRA key in the footer matching the following regex:

        ([A-Z][A-Z0-9]{1,9}-\\d+). It does not technically need to be prefixed

        with Issue-Id: it's just a good convention.


        5) Is there a Signed-off-by line in the footer of the person uploading

        the change

        1. Skip Wonnell

          I receive a "failed to check if issue exists" error from git review.   Is the Issue-ID field the correct location for the JIRA  number?   Im using this issue:   APPC-87 - Getting issue details... STATUS

          $  git log -1
          commit a241c44c21d99f0e91bf28eef218d404a98f87de
          Author: Skip Wonnell <xxxxx@xxxxx>
          Date:   Sat Aug 12 12:29:07 2017 -0500

              Update license plugin to exclude Json
              
              Change-Id: Ia18ab61c69de7f522e1483ebe85ae54dcc419c84
              Signed-off-by: Skip Wonnell <xxxxx@xxxxx>
              Issue-ID: APPC-87


          $  git review -D
          remote: Processing changes: refs: 1, done            
          remote: Failed to check whether or not issue APPC-87 exists        
          remote: java.io.IOException: RestClientException{statusCode=Optional.of(403), errorCollections=[]}        
          To ssh://skipwonnell@gerrit.onap.org:29418/appc.git
           ! [remote rejected] HEAD -> refs/drafts/master/jsonLicenseFix (Failed to check whether or not issue APPC-87 exists)
          error: failed to push some refs to 'ssh://skipwonnell@gerrit.onap.org:29418/appc.git'




          1. Alka Choudhary

            As per the guidelines given on (Commit Messages), Issue-ID should come before Change-Id. Signed-off-by should be the last statement in your "external references" section or in the footer. Though on the link page it doesn't talk about this sequence and what can break if not followed, but you can give a try by pushing Issue-ID above Change-Id.

      2. Michael O'Brien

        The multi-line commit structure works very well - reviews are still referenced back to the JIRA

        Follow

        CommitStructure

        and use a "git commit --amend" for reviews already in progress.

        /michael

  7. Chris Lott

    Suggest explaining on this page that reviews receive "Verified +1" by the automated build job if it succeeds, or Verified -1 if the build fails. Ideally (warning) reviewers should wait for the build to succeed before adding their +1 and +2 votes.

  8. Dominic Lunanuova

    I tried the run-sonar magic word today, and jenkins did the right thing!  But the log has this detail:

    22:13:38 [INFO] ANALYSIS SUCCESSFUL, you can browse https://sonar.openecomp.org/dashboard/index/org.onap.dmaap.dbcapi:dbcapi
22:13:38 [INFO] Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
22:13:38 [INFO] More about the report processing at https://sonar.openecomp.org/api/ce/task?id=AWHeemJfzx5cPqX52pyx

    We are no longer openecomp.  Worse, that URL takes me to some android.googlsource.com server.  Of course, it doesn't have the sonar results.

    I have no idea who to report this to, so hoping the owner sees this comment and reconfigs something.


    NOTE: meanwhile, I discovered that substituting "onap" for "openecomp" in the URL does resolve properly.

  9. Matthieu Geerebaert

    I didn't figure how to push a feature branch to gerrit, as I want to persist/save remotely my local branch. I'm not trying to run a git review, as it works perfectly, just to push a branch (smile) Does that make sens or is it useless ?

    I got for instance:

     ! [remote rejected] EXTAPI-44 -> EXTAPI-44 (prohibited by Gerrit)



    1. Chris Lott

      This is one of the weaknesses (or strengths depending on how you see it :-) of Gerrit.  In general the projects are configured so that contributors cannot push up branches. To collaborate with others in a branch a project committer can create the branch in Gerrit.

      You might consider publishing your changes as a new review into Gerrit using the DRAFT feature (--draft command line option), which indicates it should not be built (verified), should definitely not be merged etc.

  10. Pamela Dragosh

    Kenny Paul and Andrew Grimberg - is it possible to add a trigger for the CSIT tests? We had one fail due to mysql issue. Or do we have to remerge?

    1. Andrew Grimberg

      That really depends upon how the jobs are currently triggering. If they are triggered from an upstream job that passes in data, then no. If they are triggered directly from a change in Gerrit, then yes.

  11. Mark Leonard

    # stage your changesgit add -am "your commit message"# commit your staged changes with sign-offgit commit -s --amend
    Is there a technical reason for amending the commit here? Is it necessary to write the message in two steps?

    1. Dominic Lunanuova

      This page seems to separate the sign-off (-s) step.   But, another page, shows it all in one step. ( i.e. git commit -asm 'Initial code import')

      Either way, one other reason for using --amend is to get the opportunity to add the JIRA reference to the message body. (e.g. Issue-ID: JIRA-999)

      1. Tian Lee

        You don't need to add the commit message in-line with the "git add" command. The "git commit -s" command will allow you to specify the commit message and the Issue ID in one go, thus avoiding the need to amend the commit.

        This is what I usually do:

        git add .

        git commit -s          # Insert commit message + issue id at this stage

        git review

  12. Kevin Smokowski

    What git workflow does ONAP use? Is it the feature branch workflow?

    1. Andrew Grimberg

      The project is using Gerrit as their git SCM and code-review platform. As such, they are using the Gerrit workflow. The general overview of it is detailed in our common Release Engineering documentation related to Gerrit but also in the online Gerrit User Guide 

      Essentially, everything is developed directly against master, but long patch series chains can be in play and open at any time because of how Gerrit operates.

      1. Kevin Smokowski

        I'm not sure I have heard the term "Gerrit workflow" before. I don't think either link provided hard branching rules for example in the first link "Replace origin/master with whichever remote/branch you need to contribute to. Typically master is the latest development branch.". It seems like ONAP follows the typical pattern of master being the latest.

        At any rate "change reviews" or "git reviews" seem to function the same way as a feature branch. Latest development is done on master and then a release is cut from master at a certain date. Only a single release is worked on at a time, old releases only receive patches, correct?

        1. Andrew Grimberg

          No, either link isn't going to provide hard branching rules, they describe the general workflow of working with Gerrit.

          It's essentially what you just described, the major difference to working with other git flows is that when you're asked to make changes you don't submit a "new" change, you amend your current change and resubmit that for review. If you were doing this on GitHub you would have to do a force push to get that change back up and you would lose the previous change, but in Gerrit that historical stepping stone is preserved what gets finally merged is the accepted end change.

          So, yes, ONAP treats master as the development branch (most Gerrit projects do this). New features are developed as individual changes, or change series with a topic (virtual development branch) and then merged in once fully accepted by the core project committers.

          Release branches are created for service release / update changes to a release. ONAP itself is historically not doing service releases, but other projects like OpenDaylight do service releases. In those cases, the fixes are made to master and then cherry-picked, or appropriately reworked to the stable branch before the next service release.

  13. Michael O'Brien

    Before using a new nodeport to expose a particular service in kubernetes - check the OOM NodePort List and deploy the entire system to verify there are no conflicts before merging any oom related code - or the deployment will fail when your change is used in a full deploy.