On Feb 16, 2017, at 6:39 PM, Zoltán Kócsi <zol...@bendor.com.au> wrote: > > The itch I want to scratch is what I described: automated generation of > binaries and documentation on the server at certain points in time.
See attached existence proof. :) It’s not exactly Jenkins, but whadda ya want for a shell script hacked together in a couple of hours? Notes for adapting this to your unique purposes: 1. Adjust the variables at the top of the file to suit: 1a. checkouts: where you keep the Fossil checkouts corresponding to the RSS events we’ll be parsing. 1b. repo: HTTP URL of the server that will produce the RSS feed. Give it everything short of the “/timeline.rss…” bits. It builds and appends the rest. 1c. user & pass: user name and password of a user with permission to retrieve the RSS feed. As the script says, this user needs at least “checkout” privilege, since for no clear reason that’s the permission used for pulling the full RSS feed. If you expand this script to do fresh clones and such, the user will need those privs as well. I do recommend using a low-privilege special user with an impossible to guess random password for this. 2. Modify the list in the “for tag in...” loop to include the tags you want it to monitor. 3. It doesn’t try to cope with the possibility that multiple events have occurred since the last time it looked. It will only do the first event matching the tag. If you can check two releases in that both need a rebuild in the time it takes one build to complete, you’ll need to change the n=1 bit and make it smart enough to iterate through the set of matches returned by timeline.rss. This should be straightforward. 4. It purposely doesn’t remove the ~/.builder/$tag.event file on build failure, since I don’t want a failed build to be retried until another build comes along and fixes it. But, you might want to do something more intelligent here than just scream-and-die. 5. You’ll need xmllint from the libxml2 project installed on your system to parse the retrieved RSS feed. 6. You’ll need to adjust the <title> tag parser to extract the bits you care about. The script as shown expects the checkin comment format we use here for our “make release” process. 7. You’ll probably have to adjust the core “make rpm” command, unless by some odd chance that’s how you build your packages, too. More complex needs should be straightforward to add, given this as your shell. For instance, here we have sub-projects underneath each monitored tag, so we need to figure out which sub-project to build, which modifies the generation of cdir and other things.
builder
Description: Binary data
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
