Rename travis.cfg to ci.cfg

[do3cc]

Because this is what it really is.
There is

• jenkins
• gitlab-ci
• travis
• circle.io
• buildbot

...

[tisto]

travis.cfg contains the travis configuration, not jenkins or any other ci. If we want to add an example jenkins config, where would we put it? Changing the name also means that we will end up with many repos that have either travis.cfg or ci.cfg. There needs to be always a very good reason for renaming. I don't see that here.

[do3cc]

Hi tisto,

I should have filled out the three dots...
There is nothing travis specific in travis.cfg. I can and do use it here in jenkins and gitlab ci setups. I believe that it is a bad idea to have many different cfg files for different CI tools, this hurts readability and would quickly induce lots of repeated configuration.
Instead I'd suggest that all CI related configuration goes to ci.cfg. If something in the ci is not applicable for every ci system, that part is not part of the parts section.
the CI system does not care if the buildout command gets long.
This works perfectly well in every ci system:
./bin/buildout "buildout:parts+=travis_specific1 travis_specific2" -c ci.cfg

These are my concerns.
They are also based on my experience when we had jenkins and travis cfgs active in ploneintranet.

[jensens]

if its possible to have a general ci.cfg - a big +1 from my side.

[tisto]

I agree that right now our travis.cfg does not contain any specific configuration and we could rename it to ci.cfg. Though, a possible jenkins.cfg will contain such specific configuration for sure and every change in the file naming will confuse people. Even more if we rename it back once we want to include a jenkins.cfg. We will not be able to rename travis.cfg to ci.cfg everywhere, this will lead to confusion for sure. The main question is, is this minor name change worth the confusion it will cause?

Spreading functionality across multiple buildout configuration files (ci.cfg, travis.cfg, jenkins.cfg) is one of our major problems in my opinion (in general), just because buildout allows us that kind of flexibility, we shouldn't use it if we can get away with simple configuration files ("Simple is better than complex"). Even if that means duplication of configuration. It is just impossible to figure out how things work without looking at every single buildout file.

bobtemplates.plone currently targets single package add-ons that are best tested on travis. This is why I think the naming makes sense. I think we should even include more detailed documentation how to set up the package on travis.

In my experience the current bobtemplates.plone is not suited very well for the Aspeli-style multi package scenario. The inline buildout confuses even experienced Plone developers. I would suggest to discuss the main scenarios first, and then move on to the naming discussion. Maybe we need a separate buildout template for the non-travis use case anyways.

[do3cc]

I can life with that. regarding buildout, yes, there are some Problems

[tisto]

@do3cc @jensens @pbauer maybe we can schedule a hangout during the upcoming sprint in Munich to discuss about future directions of bobtemplates.plone.

[jensens]

@tisto lets do it

[do3cc]

I want to be there on Wednesday and Thursday. Still waiting for getting accepted in the coactivate event though :-)

cc @saily