ah ok yes I realised that it was a complex process one build triggering the other build but I did not notice it was triggered manually. Yes I agree thats a good idea but I expected this control to be at Configuration level by having a "stable" release. On Wed, Sep 10, 2014 at 12:25 PM, Ben Coman <btc@openinworld.com> wrote:
kilon alios wrote:
So I re downloaded PharoLauncher using this link https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/ lastSuccessfulBuild/artifact/pharo-ci/Pharo%203.0.0.dmg
and it is not the latest version as it does not contain the latest commit which is my commit with the new progress bar. At first I thought that it was loading something else than bleedingEdge configuration but I don't see anything else in the ConfigurationOfPharoLauncher. Am I doing something wrong ?
Notice at [1] that its upstream trigger is [2] which has no upstream project, and all builds have been started by Damien by hand (hover over the person icons). I guess the approach is that uploads to the PharoLauncher repository can be fairly unrestricted, with only the risk only of breaking [3] as the bleeding edge CI job (also trigger by Pharo bleeding edge updates). I like this approach since it helps collaboration and review of changes, with less fear uploading a change will break the world, with more quality control applied to [1] as a "Release" mechanism. [1] https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Mac-Package/ [2] https://ci.inria.fr/pharo-contribution/job/ PharoLauncherFinalUserImage/ [3] https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
cheers -ben