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 <[email protected]> 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 > >
