I think setting up a working branch is explained here: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git
Permission requirement from page: "we simply need to add your SSH public key to the working repository to give you permission to publish branches." I could set it up to pull and process into a test directory from the working branch. I would not be able to process ever 5 to 15 minutes. The current server is pretty limited hardware wise and we already have a large number of sites running on it besides the documentation. Hourly checks might be the best I can do on this server. Robert Robert Soulliere, BA (Hons), MLIS Digital Systems Librarian Mohawk College Library [email protected] Telephone: 905 575 1212 x3936 Fax: 905 575 2011 ________________________________________ From: [email protected] [[email protected]] On Behalf Of Remington Steed [[email protected]] Sent: December 6, 2013 9:15 AM To: Documentation discussion for Evergreen software Subject: Re: [OPEN-ILS-DOCUMENTATION] Using master branch to test docs Ah, right. It’s helpful to hear from someone who makes regular use of the master branch! I like the idea of having a test branch in the working repo, especially if it builds the docs more frequently. If the rest of DIG agrees, who has permissions to setup the working repo branch? It sounds more specialized than a collab branch. Robert, would you then be able to setup the automated builds, similar to the nightly build now? You could make it as frequent as you feel comfortable with (every 15 minutes? every 5?), and maybe it could only do the build if there have been changes in /docs. Remington -- Remington Steed Electronic Resources Specialist Hekman Library, Calvin College http://library.calvin.edu/ From: [email protected] [mailto:[email protected]] On Behalf Of Dan Scott Sent: Thursday, December 05, 2013 5:27 PM To: Documentation discussion for Evergreen software Subject: Re: [OPEN-ILS-DOCUMENTATION] Using master branch to test docs Uh... "Using master as the test instance" makes my spine tingle in a bad way. Rather than polluting the actual master branch history with a bunch of "maybe this will work..." doc commits, why not have a master_doc branch in the working repository that simply tracks master where you could push experiments, and have a set of automated builds for PDF, epub, html against that branch (perhaps on a more frequent basis)? Then you could fix and potentially rebase bad doc commits before pushing those to the actual master and other branches. On Dec 5, 2013 5:06 PM, "Remington Steed" <[email protected]<mailto:[email protected]>> wrote: Hi DIG, In response to Yamil’s question at the meeting today, I had this idea. When publishing docs, we could use the master branch as our test version. If it breaks, it's okay because it's only the dev version of the docs! If people check the 2.5 version (or other versions) of the docs, they will still work fine. Then you can fix the dev version, check it the next day, and then apply your fix to the current docs branches (e.g. 2.5 and 2.4). So, you should still test AsciiDoc syntax on your own machine (or using Gist, as explained here<http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:how-to-contribute-documentation&#quick_start_for_new_contributors>), then push your contributions to the master docs as the next level of testing, then finally push your contributions to the other versions of the docs. Remington -- Remington Steed Electronic Resources Specialist Hekman Library, Calvin College http://library.calvin.edu/ _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected]<mailto:[email protected]> http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation This E-mail contains privileged and confidential information intended only for the individual or entity named in the message. If the reader of this message is not the intended recipient, or the agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited. If this communication was received in error, please notify the sender by reply E-mail immediately, and delete and destroy the original message. _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
