automated checking for new versions of a package in order to trigger a build cycle

I'd rather like to monitor a number of packages and trigger a build cycle  when something new has been spotted; sort of a CI server setup for internal use.

There's bits of what look like partial solutions to this scattered around the image but I'm not spotting quite what I want so far. There's methods to query repositories about latest versions, but they seem to be not quite what I need. I could imagine using MCConfigurations somehow but it's still a bit vague.

Has anyone already done something of this sort? I'm keen to avoid wasting time if this is a solved thing.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Never do card tricks for the group you play poker with.

Hi,

> On 2020-11-04, at 11:54 PM, Marcel Taeumel <[hidden email]> wrote:
>
> We do a cron job for squeak-app to create the updated bundles for files.squeak.org. Daily for Trunk, monthly for releases. In-image changes are not propagated to GitHub or TravisCI.
>
> You could avoid a cron setup by -- after any change in your selected packages -- writing stuff to some related repository which can then be tracked through GitHub/TravisCI.

Well that all seems rather heavyweight; a sizable external component etc. I'm hoping to avoid that if at all possible.

Right now the code does a braindead simple build-everything, wait X minutes, loop. There are two problems (at least) with that
 - it does a build whether or not any code has changed, wasting cpu etc
 - if the build happens to start at a time when someone is in the middle of saving several packages you have the potential for 'fun' clashes.

But I'd also like to have it work so that as soon as possible after saving a package there is a fresh build, an obvious clash with the second point above.

This is what made me think that some use of MCConfiguration might be good. I save some packages, press a Magic Button(™) to update the configuration in the repository, the build machine does its regular (every 10 minutes or so?) check on the configuration, detects that it has changed, and thus spawns a build.

So I see three uses of the config
a) developer updates it when a chunk of work affecting one or more packages is published
b) build machine simply checks it intermittently and needs only to find out if it changed in any manner. Simply comparing a recorded versions number against the latest?
c) the image being built loads the latest config

Make any sense?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PFM: Pray For Miracle

Well it looks like one can do this without too much pain; always nice.

Once you have a config map saved in the repository it is possible to find the version number with sometihng like
        |  myRepo |
        myRepo := MCHttpRepository
                location:'http://squeaksource.sageteasoftware.com:8089/SqueakPort'
                user: 'freddy'
                password: 'kreuger'.
        ^(myRepo  highestNumberedVersionNameForPackageNamed: configNameString) versionNumber

Keep track of the highest known value and compare to decide on whether to build.

This way you get a build if the map is updated, which actually solves the potential problem of several packages needing to be saved in a group.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Advanced BASIC