Reverted doc and test names back to original
authorTodd Lyons <tlyons@ivenue.com>
Tue, 29 Oct 2013 18:56:53 +0000 (11:56 -0700)
committerTodd Lyons <tlyons@ivenue.com>
Tue, 29 Oct 2013 18:56:53 +0000 (11:56 -0700)
Installation.md

index f14687ab5b1710e65e715ee398ce6bbc15c3c55b..60b8bf49ad2e8fff0388ffafa2cd4a345a468645 100644 (file)
@@ -27,7 +27,7 @@ This will create the repo checkout in the directory *~/code/*.
 12. Test the configure process by running `./run_build.pl --test --verbose=2 --only-steps=configure`. If there are errors, you'll need to correct them until the process succeeds (ends with OK).  You can repeat this as many times as necessary because test mode does not store the status of the git repo or the status of each stage of the build.
 13. Test the build process by running `./run_build.pl --test --verbose=2 --only-steps=configure,make`. If there are build errors, make adjustments, install additional packages, etc, and repeat the test.
 14. Test the test suite by running `./run_build.pl --test --verbose=2 --only-steps=configure,make,test --override range_num_tests='1 2'`.  If there are build errors when building the test suite, or runtime errors trying to run the test suite, you may need to install additional packages (you shouldn't though).
 12. Test the configure process by running `./run_build.pl --test --verbose=2 --only-steps=configure`. If there are errors, you'll need to correct them until the process succeeds (ends with OK).  You can repeat this as many times as necessary because test mode does not store the status of the git repo or the status of each stage of the build.
 13. Test the build process by running `./run_build.pl --test --verbose=2 --only-steps=configure,make`. If there are build errors, make adjustments, install additional packages, etc, and repeat the test.
 14. Test the test suite by running `./run_build.pl --test --verbose=2 --only-steps=configure,make,test --override range_num_tests='1 2'`.  If there are build errors when building the test suite, or runtime errors trying to run the test suite, you may need to install additional packages (you shouldn't though).
-15. If you enabled the documentation building process in the *build-farm.conf*, then you can try to build it with `./run_build.pl --test --verbose=2 --only-steps=configure,build_docs`.  For documentation generation to succeed, it will require extra packages to be installed to support xml, xslt, pdf, and a few other things.
+15. If you enabled the documentation building process in the *build-farm.conf*, then you can try to build it with `./run_build.pl --test --verbose=2 --only-steps=configure,make-doc`.  For documentation generation to succeed, it will require extra packages to be installed to support xml, xslt, pdf, and a few other things.
 16. If you can get past each of these steps, then your build farm system meets the minimum requirements.
 17. The official process can be kicked off by running `/home/farm/code/run_cron.sh --run-all`.  This will run the default build configuration, keep track of the git repository status, and upload the build results to the server.
 18. Once that command runs with no complaints, add it to the **farm** user crontab.  You can run it at whatever frequency you choose, I suggest 1 hour.  If a previous instantiation is still running, the script will detect the lockfile and exit so as not to step on each other.
 16. If you can get past each of these steps, then your build farm system meets the minimum requirements.
 17. The official process can be kicked off by running `/home/farm/code/run_cron.sh --run-all`.  This will run the default build configuration, keep track of the git repository status, and upload the build results to the server.
 18. Once that command runs with no complaints, add it to the **farm** user crontab.  You can run it at whatever frequency you choose, I suggest 1 hour.  If a previous instantiation is still running, the script will detect the lockfile and exit so as not to step on each other.