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 <[hidden email]> wrote:

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

Stéphane Ducasse 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?

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

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:

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.





--
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

--
Mariano
http://marianopeck.wordpress.com