On Mon, Apr 4, 2011 at 15:40, Colin Barrett <co...@springsandstruts.com>wrote:
> How it works:
>
> buildbot has an array of repos and branches (repos are paths on "
> hg.adium.im" so "adium" an "adium-1.4", branches are in repository
> branches). When it builds each one, it injects NIGHTLY_REPO and
> NIGHTLY_BRANCH into the environment. (This is new as of last night -- right
> now that list simply contains ("adium", "default"). All nightlies, branch or
> not, will be using the same infrastructure.) To add a new one, you'll need
> to modify master.cfg. (This could probably be automated if it happens
> enough.)
>
> That information gets used by the release makefile to set some Info.plist
> keys. The parameters "repo" & "branch" are then passed along when we hit the
> Sparkle update URL.
>
> When the nightly is uploaded, it's now stored in a directory on the server
> like "repo-branch". The two scripts that look for nightlies have been
> modified to look in the right places. When a branch is merged in to trunk,
> deleting its directory on the nightly server is enough to get it to fall
> back to the default branch of the repo, or to the default branch of adium as
> a last resort.
>
> Pretty much the only outstanding issue is presenting a list of alternative
> nightlies for display on nightly.adium.im.
>
The adium-side changes seem solid.
On the sparkle side of things, I think the appcast-nightly.php changes need
a little modifications. With the changes, existing_branch() will be pinging
the nightly server on each invocation, which means for every user update
check; this is a bit too much for my blood.
How about this:
(1) Check and see if a cache file exists for the requested latest.info
(2) If the file exists, and isn't out of date, use it.
(3) If the file exists, but is out of date, update it.
(4) If the file does not exist, try and ping the nightly server to see if
it's real.
Otherwise the changes seem good.
--
Zachary West
