[Pharo-project] Process questions about configurationOfâ¦.
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
I like the idea. I wonder how you resolve dependencies & failures. Cheers, Mike On 7 Jan 2012, at 11:39, 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
On Jan 7, 2012, at 1:09 PM, Michael Roberts wrote:
I like the idea. I wonder how you resolve dependencies & failures.
simply if it barks then we cannot load it so -> broken. In the first version we would just load the ConfigurationOf not copy all the packages. try and learn. Stef
Cheers, Mike
On 7 Jan 2012, at 11:39, 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
Stéphane Ducasse 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
Some questions out of curiosity since I'm not yet involved in publishing any packages Is there some way to tag for the submitter to be emailed the Jenkins results? Perhaps a method like 'emailJenkinsResultsTo:' inthe configuration or alternatively Jenkins might unzip the mcz to directly search the ".st" files for a specific string. As I understand it, the ConfigurationOfXXX contains information on multiple versions and multiple platforms. Thinking ahead to when there is a MetaRepoForPharo14, are there any concerns keeping two versions of ConfigurationOfXXX in sync between the two repos? For example when an application releases a new version for Pharo13, do you only update the ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with further forks for ConfigurationOfXXX on other platforms? What about a single repository (if not the existing MetacelloRepository then perhaps MetaRepoCI), which Jenkins processes and then if that single file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works for Pharo14 then it is copied to toMetaRepoForPharo14. Other platforms can do the same. That way the application developer has to manage a single location. cheers, Ben
Some questions out of curiosity since I'm not yet involved in publishing any packages
Is there some way to tag for the submitter to be emailed the Jenkins results? Perhaps a method like 'emailJenkinsResultsTo:' inthe configuration or alternatively Jenkins might unzip the mcz to directly search the ".st" files for a specific string.
As I understand it, the ConfigurationOfXXX contains information on multiple versions and multiple platforms. Thinking ahead to when there is a MetaRepoForPharo14, are there any concerns keeping two versions of ConfigurationOfXXX in sync between the two repos? For example when an application releases a new version for Pharo13, do you only update the ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with further forks for ConfigurationOfXXX on other platforms?
the idea is that you should keep the master in your project and publish to the repository when you want to make your configuration available.
What about a single repository (if not the existing MetacelloRepository then perhaps MetaRepoCI), which Jenkins processes and then if that single file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works for Pharo14 then it is copied to toMetaRepoForPharo14. Other platforms can do the same. That way the application developer has to manage a single location.
Some thoughts that comes to my mind: - What if the project depends on external stuff? Let's put dbxtalk: for the tests running ok, you have to install opendbx + several databases. And since it's a pain to perform a special install for every project with special necessities, this kind of projects should be considered as a special case perhaps... - And what if the project has no test cases? hehe - Should the process care about overrides between packages? :/ We can have conflicting projects... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= BTW, If a person takes care of publishing the package to the metarepo inbox, isn't it enough to consider the package to be included as it is? It's a lot of work to certify each project :/ Guille On Sat, Jan 7, 2012 at 1:25 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Some questions out of curiosity since I'm not yet involved in publishing any packages
Is there some way to tag for the submitter to be emailed the Jenkins results? Perhaps a method like 'emailJenkinsResultsTo:' inthe configuration or alternatively Jenkins might unzip the mcz to directly search the ".st" files for a specific string.
As I understand it, the ConfigurationOfXXX contains information on multiple versions and multiple platforms. Thinking ahead to when there is a MetaRepoForPharo14, are there any concerns keeping two versions of ConfigurationOfXXX in sync between the two repos? For example when an application releases a new version for Pharo13, do you only update the ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with further forks for ConfigurationOfXXX on other platforms?
the idea is that you should keep the master in your project and publish to the repository when you want to make your configuration available.
What about a single repository (if not the existing MetacelloRepository then perhaps MetaRepoCI), which Jenkins processes and then if that single file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works for Pharo14 then it is copied to toMetaRepoForPharo14. Other platforms can do the same. That way the application developer has to manage a single location.
first - let us focus on 95% of the cases. - we do not want overrides now in any case if you load a configuration from a given see you should get a working system. Stef On Jan 7, 2012, at 6:49 PM, Guillermo Polito wrote:
Some thoughts that comes to my mind:
- What if the project depends on external stuff? Let's put dbxtalk: for the tests running ok, you have to install opendbx + several databases. And since it's a pain to perform a special install for every project with special necessities, this kind of projects should be considered as a special case perhaps...
- And what if the project has no test cases? hehe
- Should the process care about overrides between packages? :/ We can have conflicting projects...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
BTW, If a person takes care of publishing the package to the metarepo inbox, isn't it enough to consider the package to be included as it is? It's a lot of work to certify each project :/
Guille
On Sat, Jan 7, 2012 at 1:25 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Some questions out of curiosity since I'm not yet involved in publishing any packages
Is there some way to tag for the submitter to be emailed the Jenkins results? Perhaps a method like 'emailJenkinsResultsTo:' inthe configuration or alternatively Jenkins might unzip the mcz to directly search the ".st" files for a specific string.
As I understand it, the ConfigurationOfXXX contains information on multiple versions and multiple platforms. Thinking ahead to when there is a MetaRepoForPharo14, are there any concerns keeping two versions of ConfigurationOfXXX in sync between the two repos? For example when an application releases a new version for Pharo13, do you only update the ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with further forks for ConfigurationOfXXX on other platforms?
the idea is that you should keep the master in your project and publish to the repository when you want to make your configuration available.
What about a single repository (if not the existing MetacelloRepository then perhaps MetaRepoCI), which Jenkins processes and then if that single file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works for Pharo14 then it is copied to toMetaRepoForPharo14. Other platforms can do the same. That way the application developer has to manage a single location.
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
Isn't there a pragma or something to mark an expected failure ? On 08/01/12 13:20, Mariano Martinez Peck wrote:
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?
-- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225
On Sun, Jan 8, 2012 at 10:51 PM, Francois Stephany < tulipe.moutarde@gmail.com> wrote:
Isn't there a pragma or something to mark an expected failure ?
Indeed :) thanks for the reminder. Well, forget about that item. Still the question of what happens if 80% of the tests are green. Ok or broken?
On 08/01/12 13:20, Mariano Martinez Peck wrote:
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?
-- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225
-- Mariano http://marianopeck.wordpress.com
participants (6)
-
Ben Coman -
Francois Stephany -
Guillermo Polito -
Mariano Martinez Peck -
Michael Roberts -
Stéphane Ducasse