This captures committer-specific information beyond what's covered in the contributions guide.
Accepting Pull Requests on GitHub
The ASF INFRA team maintains a mirror of our git repository over on GitHub.That mirror is strictly one-way: changes from the Apache git get copied over, but not the other way around. Further, the mirror on GitHub is read-only for everyone. Which means we can neither accept nor close pull requests filled there via the GitHub web UI. However, we want to allow for contributions via GitHub Pull Requests. Here's how:
Add the ASF git repository
See this guide.
Merge changes
The next step is to merge all changes on the Pull Request as a single commit. There are two methods here: (A) pull the branch from the GitHub Pull Request and squash commits, or (B) get the .diff
from GitHub and manually create a commit from this information. Each option has its pros and cons. With method A, git does some of the tedious work of preserving commit messages; but in some cases the squash may not apply cleanly, and the merger will have to carefully resolve conflicts. With method B, the .diff
will apply cleanly (given that the branch is up-to-date, i.e. the GitHub GUI states that the "This pull request can be automatically merged by project collaborators"); but the merger will have to carefully copy over commit messages and edit author information.
Check the commit message
See this guide for what to look for.
Resolving issue vs Closing issue
The last step of merging a pull request is resolving the associated issue. Committer should resolve it, provide the current release number (the latest unreleased version) in "Fix version" field and provide a link to the pull request in the comment.
Issue should be closed only if no productive steps were taken for it, i.e. it is "won't fix" or "duplicate" or "contained by". If some work was done but it doesn't have pull request associated with it, the issue should be resolved by the person who did the work.
Method A
PowerShell setup instructions contain functions which wrap the following actions and make committer's life easier.
A-1. Create a branch on your local git repository
You want to make sure that that branch is current with the the master branch on Apache git:
...
This assumes that you called the remote git repository at the ASF "apache". You can name the branch however you want, but it is customary to name them either after the pull request number or the JIRA id, e.g. REEF-24.
A-2. Pull the contribution into that branch
This is as simple as
Code Block | ||
---|---|---|
| ||
$ git pull GIT_REPOSITORY_OF_THE_CONTRIBUTOR BRANCH_NAME_OF_THE_CONTRIBUTION |
...
This copies the changes from the given remote branch into the one we just created locally.
A-3. Check the pull request
- Make sure the code compiles and all tests pass.
- If the pull request changes any POM.xml file: Please either clean your local maven repository before testing OR wait for the build servers to confirm that the project builds. This is to avoid situations in which an artifact was renamed or removed but is still in your local maven repository.
Test java code
At REEF root folder
Code Block title Run Java Tests mvn clean install
Test .Net code
To run tests in command line, go to folder $REEFSourcePath\lang\cs\ and build the projects with the command line:
Code Block title Build .Net source code in debug mode msbuild Org.Apache.REEF.sln
Where $REEFSourcePath is REEF source code root folder.
Then run xUnit tests:
Code Block title Run .Net Tests using msbuild msbuild TestRunner.proj
Alternatively, open $REEFSourcePath\lang\cs\Org.Apache.REEF.sln in VS, rebuild entire solution, then run all tests in Test explore.
If the code touches code that you suspect might break on YARN or Mesos, please test on those environments. If you don't have access to a test environment, ask on the mailing list for help.
Make sure the code adheres to our coding guidelines.
Make sure that the additions don't create errors in a Apache RAT check via
mvn apache-rat:check
A-4. Rebase the branch onto current apache master
Code Block | ||
---|---|---|
| ||
# Make sure we have the latest bits $ git fetch apache # Rebase $ git rebase -i apache/master |
...
Code Block | ||
---|---|---|
| ||
$ git commit --amend |
A-5. Push the code into apache's git
This is a good time to reflect back on this change and whether it is likely to break the build. If you are certain that it won't, go ahead and do:
...
This pushes the current branch into the master branch hosted on Apache's git repository. From there, it will be mirrored onto GitHub. And by virtue of the comment added above to the commit message, GitHub will now close the Pull Request.
Method B
B-1. Update local master
In this method, you will work directly on your local master branch. Make sure you have the latest changes on your local master branch, by running:
Code Block | ||
---|---|---|
| ||
$ git pull apache master |
B-2. Download the .diff
and apply it
You can download the .diff
file by appending .diff
to the GitHub Pull Request url. This file will contain the exact changes that are shown in "Files changed" in the GitHub GUI. For example, for https://github.com/apache/reef/pull/24
the .diff
file is https://github.com/apache/reef/pull/24.diff
. Using this url, run apply:
Code Block | ||
---|---|---|
| ||
$ wget https://github.com/apache/reef/pull/24.diff $ git apply 24.diff |
B-3. Commit and edit author information
Commit all files, making sure to include all modified and new files. In the commit message, make sure to include all information given in "Commit Message" above. After committing you must also change the author information to reflect the original author (and not yourself):
Code Block | ||
---|---|---|
| ||
$ git commit --amend --author "Original Author Name <email@address.com>" |
B-4. Push the code into apache's git
Now push your single commit to apache git:
...