![]() Given how fetch works, the example command above will retrieve all of the code in the branch you're interested in but it won't affect any of your local branches since nothing is merged with fetch. If you only have one remote repo then you can omit all of the arguments to git fetch, which will retrieve all branches and updates, and then run git checkout since all remote branches are already on your system. Once everything has been downloaded from the remote repo you can then check it out to actually inspect and play around with the code. Step 1: Do a clean compile of both MPI debug and MPI release versions of the code.The fetch command will retrieve the remote branch you're interested in and all related objects and references, storing it in a new local branch that you specified by the argument. The downside of using Run_FDS_Cases.sh is that there are a few things you must do manually, but these are really not too onerous. Last, it may be that you only want to run a subset of the cases, in which case you could comment out other cases in FDS_Case.sh, or modify scripts/Run_FDS_Cases.sh (which we will talk about next) to run your select cases. Next, if your changes would pass a build, FDS run, and Matlab plot, then it should be reasonable to merge and let the full Firebot run overnight. First, (at the time of writing) if you do your development on a machine other than blaze (I use burn or my laptop most of the time), it is a hassle to migrate your branch over to blaze for a full Firebot session. There are a few reasons why you may want to utilize this list for testing your pull request. The list of cases in the FDS verification suite is in Verification/FDS_Cases.sh. ![]() Manually Running FDS_Cases.shĪ light weight alternative to running the complete Firebot process is to manually run the verification cases. However, we note that it is advisable to carry out this process on a clean repository, else you may lose untracked files in your working directories. Going through this procedure will take you through the whole process, including building the manuals. Once you have made the changes in the test branch (add and commit them) you can push this new branch to GitHub viaĪ guide to setting up and running the FDS continuous integration program "Firebot" can be found here. If you are the developer and if you have followed the instructions to this point you will not have a copy of the new test branch in your GitHub repo. In this case, it is usually easier for the developer to make the local changes themselves and then push to their own forked repo. Often it is the case that the pull request is 99 % of the way there, but may need a few minor edits in order meet all the Developer Commit Guidelines. If there is a problem, you can either write the author to make changes and "Close and Comment" the conversation (the author will need to make another pull request) or you can make the changes yourself in your local test repo and push those to YOUR origin and submit a pull request to the central repo from there. If successful, then you can simply accept the pull request on GitHub. make_guide.sh, and we should see FDS User Guide built successfully! in addition to the correct additions having been made to the guide. In this case, we go to Manuals/FDS_User_Guide/ and run $. OK, now run your test to determine if the pull request does what it is supposed to do. (what you see here depends on what you have modified in your local repo you may want to your changes before starting this process)
0 Comments
Leave a Reply. |