Add travis-ci support for PHP 5.3+ and HHVM about core HOT 24 CLOSED

hmmm... It seems that Pear is not available under HHVM.

The following command:

pear channel-discover pear.phing.info

is returning the following error.

rbenv: pear: command not found

Maybe we should find a way to test without PHING?

from core.

Phing can be installed with Composer, or manually. Would that be better?

from core.

Well, I guess if it could be installed with Composer it would be MUCH better 👍 Thanks :)

I have little knowledge about Phing and what it does... I guess I need to setup my own travis-ci to test what you have suggested.

from core.

Phing can be installed with Composer, or manually. Would that be better?

Composer is a much better option. PEAR is an old dinosaur on the way out.

On Thu, Jun 5, 2014 at 2:14 PM, Sam Wilson [email protected] wrote:

Phing can be installed with Composer, or manually. Would that be better?

—
Reply to this email directly or view it on GitHub
#504 (comment).

from core.

Well, from what I read, we are also installing Phing from Composer, no?

https://github.com/kohana/kohana/blob/3.3/develop/composer.json#L4

from core.

Reading about this more and more... It seems that this Phing thing is involved in overriding the way Travis CI works using the build.xml file... and I have the feeling that we can enable this thing Phing for all our official repos/modules and make it build the default Kohana application and test... So whenever someone PRs something Travis-CI can test it...

Too much "aha" moments for a single day... my brain :(

from core.

You can basically only test the whole system. You can't run unit tests on just a module, because it depends on the rest of the system. Ah...bad design and how it can bite you later

from core.

Thanks @zombor . Yeah, I can see that :(((

I am trying to figure out a way to tell Travis-CI to pull and build kohana/kohana, always, even if we are asking to test a module like kohana/cache.

I think this is complicated:

• We need to test for some kind of variable ${env.TRAVIS_PULL_REQUEST}, which shows if the test was triggered by a pull request. That's great, but how to build kohana/kohana from kohana/cache and have that PR included for test?
• Also while building, we need to make submodules track the branch instead of a commit, and then update to the last commit, I don't know if it is possible with Github, but here's something interesting I read (I am not sure if I am making sense):
  http://stackoverflow.com/questions/1777854/git-submodules-specify-a-branch-tag/18799234#18799234

from core.

That's great, but how to build kohana/kohana from kohana/cache and have that PR included for test?

This is why it hasn't been done. It's very hard to do. That's why we just build the whole system and all the modules in kohana/kohana in travis-ci right now I believe.

from core.

Indeed, VERY hard to do.

I am linking here some references that might be valuable:

http://docs.travis-ci.com/user/ci-environment/
travis-ci/travis-ci#1719 (comment)

Maybe we should seek for help at travis-ci forum?
https://groups.google.com/forum/#!forum/travis-ci

from core.

I have a small script at https://github.com/ingenerator/koharness - the readme is slightly out of date, but it works. Take a look for example at https://github.com/ingenerator/kohana-doctrine2

Basically, you make sure that the module's composer.json has a dependency on the other Kohana modules/core that are required (as it should do anyway).

Then when you want to build say kohana/cache, you first use composer to install the dependencies inside your module checkout.

And then you run koharness which mocks up a barebones kohana application with an index and bootstrap that loads the current module and any others that it requires - by default in /tmp/koharness. Once you have that you can run whatever unit tests you want. It would probably make sense only to run the tests for the current module to minimise false failures. That does leave a risk that a change in one of the modules breaks something in one of the others when eventually merged because of the interdependencies.

It's not especially neat, but it has been working reliably for me for a fair while and handles both pull requests and master builds.

I could set it up for one of the modules as a proof of concept fairly quickly.

from core.

Thanks @acoulton . I can see I have starred that project, but it's only now I kind of understand how it works.

So it creates an application and bootstraps it similar to kohana/kohana? and runs the tests within that frame? Well, regarding our current situation, and until the day we re-architect things, I think this is great and will help us a lot!

Now, if everyone agrees, could you donate this as an official module for Kohana? Or even better, could we integrate this into the unittest module? It's imperative to make testing easier for everybody, including for third-party module devs, also it is important to have this well documented.

It would probably make sense only to run the tests for the current module to minimise false failures. That does leave a risk that a change in one of the modules breaks something in one of the others when eventually merged because of the interdependencies.

For the official modules, it's better to see all the tests running on Travis-CI, to minimize risks.

from core.

We need to make Travis-CI work for us to test each module that has unit tests, independently.

Please advise to choose between 2 setups:

• Either use phing + travis-ci environtment vars to load kohana/kohana and test
• Or integrate ingenerator/koharness with kohana/unittest, which creates an environment similar to kohana/kohana on Travis-CI instance and runs the tests

My 👍 goes to koharness integration with unittest. Please let us know your thoughts.

Thanks.

from core.

@enov I'd be happy to contribute koharness to the official project, I should be able to squeeze out some time later this week.

I think it should be a separate package, rather than part of unittest. Unittest's composer.json depends on phpunit, but koharness can be used with any test framework (and indeed for any other tooling or whatever you might want). For example, our modules commonly use phpspec now but we'd still want to be able to use koharness without having to add unittest and phpunit.

I could either transfer the repo to the kohana organisation (I think I would require temporary admin rights) or someone could create a new repo with community team push rights and I could just get it set up in there.

from core.

@acoulton , thanks, that's amazing!

I could either transfer the repo to the kohana organisation (I think I would require temporary admin rights) or someone could create a new repo with community team push rights and I could just get it set up in there.

@shadowhand , I guess we need your help here. Would you give some admin rights to @acoulton , or maybe if you would just create the new koharness repo with community push rights?

Thanks!

from core.

@enov @acoulton A month late, but better late than never, right? I just forked Koharness to Kohana and added Community to to it.

from core.

@enov For some reason you weren't part of the Community team. I added you.

from core.

@shadowhand thanks, would it be possible to actually transfer the repo over to you? I think you'd need to:

• create a new team with admin privileges
• put me in it
• don't add any repos

Then I can transfer the repo over to you. At that point I'll also update the composer package name to be kohana/kohana and the various copyright etc statements.

from core.

@acoulton if you contact github and ask them to promote kohana/koharness to the primary/main parent, they can do that. Then your repo will appear as a fork.

from core.

@shadowhand goodo, have contacted support.

from core.

@shadowhand could you register https://github.com/kohana/koharness on https://packagist.org/packages/submit and set up the github hook - or give me temporary admin on that repo and I can?

@enov I've clarified and updated the https://github.com/kohana/koharness/blob/master/README.md a bit - see if it makes sense to you. In due course I'll also tidy up the code - it was only really built as a hack at the time.

Once kohana/koharness is showing on packagist I can set up one of the kohana modules with it and you can see it in action.

from core.

@shadowhand @acoulton I might be leaving for a family vacation within few days. Having things to catch up, i can't follow or review this now.

@acoulton, you're doing a good job. I skimmed through the readme, it'll be cooler to also add company logo besides the name at the end.

Cheers 🍺

from core.

@acoulton you now have admin on Koharness.

from core.

I forgot there was already this thread open. This is dealt with by kohana/kohana#50 and the multiple PRs to activate module builds with all these environments. I'll close this now.

from core.