You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

For project committers merging changes into git repo

Committer Process

See also, Apache page: https://git-wip-us.apache.org/

Initial Set-up

Be sure to use your apache address.

  • git config --global user.email myusername@apache.org

Check that your github user is a public member in the "trafodion-contributors" group. This allows some permissions with the Jenkins test server.

Workspace set-up for merging pull requests.

  1. In the VNC/Gnome environment, either add to your .bashrc or type in your current shell unset SSH_ASKPASS
  2. Pushing to Apache repo requires password authentication.
  3. Make sure you have a workspace cloned from github.
  4. Make sure you have a remote pointing to the Apache repo. (Setting only the push URL with username does not seem to work.)
    • git remote add apache https://USERNAME@git-wip-us.apache.org/repos/asf/incubator-trafodion.git

Automated Testing

You can interact with Jenkins testing via pull request (PR) comments. All of these commands should start with "jenkins," to not confuse other users. You can add more to the end of the message if you want. Jenkins just pattern matches the string, and will ignore trailing comments.

  • If an unknown user submits a PR, then Jenkins automation will post a message to github asking if it is okay to test.
    • Review the pull request. If the code is not malicious and is okay to test, post a comment "jenkins, ok"
  • If the author is a trusted contributor, you can add them to a white-list of known users.
    • Post a comment "jenkins, add user"
    • Consider inviting them to the "trafodion-contributors" github group as well.
  • New commits to the PR will trigger a new build. You can also trigger a retest without a new commit.
    • Post a comment "jenkins, retest"

Ensure Criteria are Met

The acceptance criteria are determined by the project committee (PPMC). They should be documented here.

  • Code Review(s)
  • Time available for comments
  • Testing
    • Be sure that you wait for all pending tests!
    • New commits, even those that are just merging with latest master branch, trigger new test run.
  • Legal
  • Other

Merge Pull Request

Note: Before beginning, make careful note of what branch you are merging to. At the top of the pull request, you'll see words like, "So-and-so wants to merge n commits into apache:target_branch from github_user:some_other_branch. Most of the time, target_branch will be "master", but occasionally you'll see a release branch instead, e.g., "release1.3". In the instructions below, if the target_branch is not "master", replace "master" with the name of the target branch.

Example of merging pull request 12345.

  1. Check the pull request status on github, at the bottom of the pull request page. It will tell you if there are any merge conflicts with master branch.
    1. If there are conflicts, either ask the contributor to merge up, or be prepared to resolve the conflicts yourself.
  2. Create a local merge branch, based on the latest, greatest.
    1. git fetch apache (you will be prompted for your apache password)
    2. git checkout -b mrg_12345 apache/master
  3. Fetch pull request branch to default destination FETCH_HEAD
    • git fetch origin +refs/pull/12345/head
  4. Merge locally, giving message that includes JIRA IDNormally, you want to just merge their branch:
    • git merge --no-ff -m "Merge [TRAFODION-XYZ] PR-12345 Whizbang feature" FETCH_HEAD
    • Sometimes you might want to squash their branch into a single commit. If so, add the "--squash" option.
    • If you forget the -m option, you end up with a less than helpful default comment.
      Before you push the commit, you can fix the comment by:
      • git commit --amend
  5. Additional checks of what you are preparing to push
    • git log apache/master..HEAD
    • git diff apache/master HEAD
  6. Push changes to Apache repo, specifying the source and the destination branch.
    • git push apache HEAD:master (you will be prompted for your apache password)

Publish Web Site Updates

If the change you are merging includes website or document updates, you should also update the project website. Look for files in the docs/ tree as well as some files in dcs/ and core/rest that affect documents.

For more info on documentation build, see Modifying Documents.

To publish the website:

  1. Fetch changes to be published from the Trafodion master branch.
  2. Build Trafodion site (source env.sh; mvn post-site).
  3. If there are documentation changes to prior releases, check out those release branch(es) and re-build the affected docs (source env.sh; cd docs/... ; mvn post-site).
  4. git clone https://ApacheUserName@git-wip-us.apache.org/repos/asf/incubator-trafodion-site.git
  5. Checkout asf-site branch (cd incubator-trafodion-site; git checkout asf-site).
  6. Copy content of trafodion build into the incubator-trafodion-site directory (cp -R trafodion/docs/target/*   incubator-trafodion-site/)
  7. Commit changes (git add --all ; git commit).
  8. Push them back to the apache origin repository to the asf-site branch (git push origin HEAD).
  9. Check that the website is refreshed.

Once pushed, Apache gitpubsub takes care of populating http://incubator.trafodion.apache.org with your new changes. If they don’t show up, pushing another commit may work to trigger the automation. Just make an innocuous white-space change to some html file, commit it and push it.

Completion

  1. Close Jira, if appropriate, or ask the contributor to do so.
  2. If ASF automation does not close the pull request, ask the contributor to do so.


Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.
Related articles

There is no content with the specified labels

  • No labels