Amazing! Speaking of Jenkins: someone just recently mentioned an existing (dusted though) Fossil plugin for Jenkins. May just be worth a try for your case. Jenkins would automate interactions with Fossil repo, with all benefits of a CI/build server. http://www.mail-archive.com/[email protected]/msg24585.html
On Thu, Feb 16, 2017 at 10:14 PM, Warren Young <[email protected]> wrote: > On Feb 16, 2017, at 6:39 PM, Zoltán Kócsi <[email protected]> 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. > > > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
