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

...