Page History

...

1. 1. Commit and Push changes

      1. Create a branch AMBARI-XXXXX-branchName before starting to make any code changes. Ex: If the Fix Version of the JIRA you are working on is 2.6.2, then create a branch based on branch-2.6
         
         

         Code Block
         language bash
         git checkout branch-2.6 git pull upstream branch-2.6 git checkout -b AMBARI-XXXXX-branch-2.6

      2. Mark the status of the related JIRA as "In Progress" to let others know that you have started working on the JIRA.
      3. Make changes to the code and commit them to the newly created branch.
      4. Run all the tests that are applicable and make sure that all unit tests pass

      5. Push your changes. Provide your Github user id and personal access token when asked for user name and password 

         Code Block
         language bash
         git push origin AMBARI-XXXXX-branch-2.6

   2. Create Pull Request

      1. Navigate to your fork in Github and create a pull request. The pull request needs to be opened against the branch you want the patch to land.

         1. The pull request title should be of the form [AMBARI-xxxx] Title, where AMBARI-xxxx is the relevant JIRA number

         2. If the pull request is still a work in progress, and so is not ready to be merged, but needs to be pushed to Github to facilitate review, then add [WIP] after the AMBARI-XXXX
         3. Consider identifying committers or other contributors who have worked on the code being changed. Find the file(s) in Github and click “Blame” to see a line-by-line annotation of who changed the code last. You can add @username in the PR description to ping them immediately or add them to the list of reviewers to the pull request.or as a comment to request review from a developer.
            Note: Contributors do not have access to edit or add reviewers in the "Reviewers" widget. Contributors can only @mention to get the attention of committers. 
         4. The related JIRA will automatically have a link to the PR as shown below. Mark the status of JIRA as "Patch Available" manually.
            
            
            

   3. Jenkins Job

      1. A Jenkins Job is configured to be triggered everytime a new pull request is created. The job is configured to perform the following tasks:

         1. Validate the merge
         2. Build Ambari

         3. Run unit tests

      2. It reports the outcome of the build as an integrated check in the pull request as shown below.
         Image Added
      3. It is the responsibility of the contributor of the pull request to make sure that the build passes. Pull requests should not be merged if the Jenkins job fails to validate the merge.
      4. To re-trigger the build job, just comment "retest this please" in the PR. Visit this page to check the latest build jobs.
         
         
   4. Repeat the above two steps for patches that needs to land in multiple branches. Ex: If a patch needs to be committed to branches branch-2.6 and trunk, then you need to create two branches and open two pull requests by following the above steps.
      
      

...

1. Other reviewers, including committers can try out the changes locally and either approve or give their comments as suggestions on the pull request by submitting a review on the pull request. More help can be found here.
2. If more changes are required, reviewers are encouraged to leave their comments on the lines of code that require changes. The author of the pull request can then update the code and push another commit to the same branch to update the pull request and notify the committers.
3. The pull request can be merged if atleast one committer has approved it or commented "LGTM" which means "Looks Good To Me" and the jenkins job validated the merge successfully. If you comment LGTM you will be expected to help with bugs or follow-up issues on the patch. (Remember committers cannot review their own patch. If a committer opens a PR, they should make sure that another committer reviews it.)
4. Sometimes, other changes might be merged which conflict with the pull request’s changes. The PR can’t be merged until the conflict is resolved. This can be resolved by running git fetch upstream followed by git rebase upstream/[branch-name] and resolving the conflicts by hand, then pushing the result to your branch.
5. If a PR is merged, promptly close the PR and resolve the JIRA as "Fixed". 

...