Note: This is a follow on to Contributing.
MOOSE uses an extensive set of automated processes and peer review to take in code from Contributors:
Contributors submit code to MOOSE by pushing their modifications to their Fork of the MOOSE repository. Then, a Contributor will submit a Pull Request (PR) to pull their modifications from their Fork into the
devel branch in the main MOOSE repository.
At the point where a PR comes in GitHub will automatically signal moosebuild.com which creates multiple "jobs" on moosebuild.com. Client processes running on our build machines will pull down the code contribution, build it on multiple platforms, run the suite of tests in MOOSE and report the results back to moosebuild.com.
moosebuild.com collates those results and then tells GitHub whether or not that code passes all of our tests. A comment will be placed on the PR and the PR will turn either Green or Red (for passing, failing respectively).
At this point, if the code passes the tests MOOSE developers will be assigned to review the code. Comments from MOOSE developers will be placed on the PR raising any potential issues.
If there are any issues with the code as submitted it is the job of the submitter to respond to the comments and take corrective action. That corrective action usually comes in two forms:
If only small fixes are required then the submitter should
amend their patch set to fix the small issues and
force push the patches back into their branch in their fork. The basic sequence for doing so is:
# In your local clone of your Fork git co branch_name # Checkout the branch you pushed to your Fork that the PR is using # make changes git add filename.C # Use "git add" to mark changes as needing to be committed git commit --amend # Amend the "top" commit to include these small changes git push --force origin branchname # Force your changes back into your branch in your Fork on GitHub
The actual commands that you can use for this step can vary... the above is just to give you an idea of what's involved. If your PR is very long-lived it may be a good idea to rebase your patches on top of any recent activity in the real MOOSE repo before the
git fetch upstream git rebase upstream/devel
You may have to fix conflicts during that stage.
If there are more features that need to be added to your code before it's accepted by the MOOSE team you can also achieve that by simply adding more patches to your branch. Always remember to reference the ticket number you are working on in the commit message for each patch that is going into MOOSE.
At the point where a MOOSE developer believes your code is fit for inclusion in MOOSE they will "merge" your code into the
devel branch in the main MOOSE repository. That act of merging automatically kicks off a set of processes:
masterbranch in the main MOOSE repo (that is our "stable" branch).
mastercues moosebuild.com to spawn jobs that automatically build:
Pull Requests that remain inactive with unaddressed comments or failed tests for a period of 30 days may be closed by any member of the MOOSE team at their discretion. These Pull Requests may be reopened by the original developer or an interested party at any time if activity resumes. These unmerged PRs can be found by using the filter