Hi Stef. I have answered what I think several times, but I will try to do one last shoot ;) I agree to what you say and I have some things to say and some questions: 1) For the implementation point of view, there must be an agreement between the jenkins and the ConfigurationOf. Several things have to be set down: WHICH VERSION to load, and for that version, which PACKAGES/GROUPS to load, and WHICH category tests to run. So...this can be easily done as conventions: a) for which version, we assume #stable (if we are building in pharo images before the current one). So say we are building in Pharo 1.3 then we always load #stable. So developers should maintain that method. If we are then building in Pharo 1.4, then I think we should use #bleedingEdge. Last option is to create a special symbol version for this special jenkins runner. b) for which package or group, each ConfigurationOf can just implement #defaultPackagesToLoadInPharo13: that answers an array with the packages/groups to load. Another posibility is to always load a specific group. Say we have a group called "CertifierGroup" and then we always load that group. c) we can just implement #testsCategoriesForPharo13 in each conf and that's all. That way, maintainers of ConfigurationOf only needs to keep #stable up to date, and just implement (for example) #defaultPackagesToLoadInPharo13 and #testsCategoriesForPharo13 2) Once the server has run and moved the conf to MetaRepoForPharo13, it is very cool because we can then after scan the repo MetaRepoForPharo13 and know that taking that conf, with that version and that amount of packages, then it should work ;) 3) What happens with tests? do we only accept 100% green tests as ok? In Fuel for example, we like to create tests before the real code. And moreover, we create tests to demonstrate things we don't support yet. So sometimes we have red tests even if there is no bug, but just a missing thing we will do in the near future. maybe we can have a treshlod ? say, 80% of green tests? 4) Answering to Guille, we don't care about overrides. I think each conf will be run in a clean pharo image as the jenkins does right now. Is it like this? 5) not as a first step, but as a future, the process of moving to MetaRepoForPharo13, could also move ALL mzc files of all the packages in order to be self-contained. But this is more complicated because then we need to use #repositoryOverrides: or something like that because even if we move mzc files our confs are pointing to another place... Or maybe we can change the confs on the fly...anyway, this is future ;) 6) once we have this repositories, we can have tools that scan those repos and let us load stuff from there. 7) Is this process propagated? Say I have ConfigurationOfGlorpDBX and I want to run this process. Such conf uses ConfigurationOfFFI. Will FFI be processed as well as glorpDBX or we only measure/analyzer the first one ? 8) Same as Guille? what happens with projects that do not have tests? There is no way to certify they work.... I would put them as broken directly ;) Sorry for the long mail. On Sat, Jan 7, 2012 at 12:39 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi guys
What is the process we want? What I would like is
MetaRepoForPharo13Inbox were everybody can write and a jenkins process that loads every published version and try to load it (after we will run tests and check rules). depending on the result the configuration is promoted into MetaRepoForPharo13 or MetaRepoForPharo13Broken
At the end of the month we will have one engineer working on jenkins and I would like to ask him to start to put in place this process.
What do you think?
Stef
-- Mariano http://marianopeck.wordpress.com