| # |
Feb 18th 2009, 14:21 |
d1rk |
alkemann: yes, especially if talking about features, but we have to do something before that, so if development cycles get shorter one could setup ci. |
| # |
Feb 18th 2009, 14:20 |
d1rk |
jperras: yeah - hehe. lets see if i can stretch this very day to 36 hours... uhm, no.. failed.. so... |
| # |
Feb 18th 2009, 14:20 |
alkemann |
being able to checkout the dev branch to an online server could be useful for sure |
| # |
Feb 18th 2009, 14:18 |
jperras |
d1rk: you make some good points, for sure. but yeah, I think we can drop this for the moment |
| # |
Feb 18th 2009, 14:17 |
d1rk |
jperras: yeah - it is of no importance right now. I was just curious... |
| # |
Feb 18th 2009, 14:17 |
d1rk |
jperras: you are right, there is need for tests. but i like the process of an automatic deployment to an online.webserver so i (and others) can always check the current state of development as oposed everybody has to fetch latest sources and test them in their own environment... |
| # |
Feb 18th 2009, 14:16 |
jperras |
in any case, I think this is a very unimportant point at this time, since individuals can create their own pre-commit hooks to ensure they haven't broken anything |
| # |
Feb 18th 2009, 14:15 |
jperras |
d1rk: not really. what's the point of having cont. integration to run all your tests if you're not writing tests as you develop more features? |
| # |
Feb 18th 2009, 14:15 |
alkemann |
i love tdd, but so far i have only made tests for behaviors, components and helpers. app tests seems like not so good in the reward/work area |
| # |
Feb 18th 2009, 14:14 |
d1rk |
jperras: it can be unrelated to code-coverage... |
| # |
Feb 18th 2009, 14:13 |
jperras |
alkemann: I tend to agree to some extent. for cont. integration to be useful, you need to maintain ~80% or better code coverage at all times |
| # |
Feb 18th 2009, 14:12 |
d1rk |
jperras: thank you. It looks promising |
| # |
Feb 18th 2009, 14:11 |
d1rk |
alkemann: if it is setup once, it makes the devs and all project-related persons happy :) |
| # |
Feb 18th 2009, 14:09 |
alkemann |
to me it sounds a little overkill, but i would be happy for the experience of doing this :) |
| # |
Feb 18th 2009, 14:02 |
jperras |
of course, you need to have the cake shell in your $PATH as well |
| # |
Feb 18th 2009, 14:02 |
jperras |
actually, that might need a little tweak; I'm not sure if the testsuite shell returns an exit value of 1 when a test fails |
| # |
Feb 18th 2009, 14:01 |
jperras |
http://bin.cakephp.org/view/1733483502 |
| # |
Feb 18th 2009, 14:00 |
jperras |
and populate it with the code in the bin: |
| # |
Feb 18th 2009, 13:59 |
jperras |
d1rk: create a pre-commit file in $BOOK_PROJECT/.git/hooks/pre-commit |
| # |
Feb 18th 2009, 13:59 |
d1rk |
jperras: sounds great. could you give me a hint how to do that? |
| # |
Feb 18th 2009, 13:58 |
d1rk |
jperras: oh, really? how do i do that? |
| # |
Feb 18th 2009, 13:58 |
jperras |
and even a pre-commit to make sure your tests pass before you do a push |
| # |
Feb 18th 2009, 13:58 |
jperras |
d1rk: you can implement your own post-commit hooks in git for test running very easily |
| # |
Feb 18th 2009, 13:57 |
d1rk |
maybe, if there is something like a web-callback in thechaw i would deploy it for myself on a test-instance, somewhere.... |
| # |
Feb 18th 2009, 13:56 |
d1rk |
jperras: i see your point, but i do not agree at all. actually every commit should try not to break everything. |
| # |
Feb 18th 2009, 13:56 |
alkemann |
if u set it up, i dont see a problem. but once we got a spec down, this is kinda of a simpe project :) |
| # |
Feb 18th 2009, 13:55 |
d1rk |
jperras: well, i like the idea of having it (actually, i use it on all my projects) because i can have a look if everything turns out as it should be. And well, it is possible to show other people as well, what had been done. |
| # |
Feb 18th 2009, 13:55 |
jperras |
and ci is really only useful for a nearly complete, stable product |
| # |
Feb 18th 2009, 13:55 |
d1rk |
alkemann: it means to have a automatic deployment to a staging-server that is initiated by a commit. |
| # |
Feb 18th 2009, 13:54 |
d1rk |
i thought we could push the latest revision onto a test-server or something on every commit. |
| # |
Feb 18th 2009, 13:54 |
d1rk |
jperras: oh, ok. |
| # |
Feb 18th 2009, 13:54 |
jperras |
two things which bakery does not yet have |
| # |
Feb 18th 2009, 13:53 |
jperras |
d1rk: you need a very well defined api and test cases for that |
| # |
Feb 18th 2009, 13:48 |
alkemann |
a what= |
| # |
Feb 18th 2009, 13:45 |
d1rk |
alkemann: is there something like a continious integration process for bakery2? |
| # |
Feb 18th 2009, 12:56 |
d1rk |
alkemann: a combination of all usually implies (at least a little bit of) quality |
| # |
Feb 18th 2009, 12:48 |
alkemann |
we can use views for popularity was my point as well |
| # |
Feb 18th 2009, 12:48 |
alkemann |
no we want quality measure i meant |
| # |
Feb 18th 2009, 12:47 |
jperras |
if all we want is a popularity metric, there's page views and # delicious bookmarks |
| # |
Feb 18th 2009, 12:45 |
alkemann |
d1rk: though, it's not good data to use quality. just popularity. |
| # |
Feb 18th 2009, 12:41 |
d1rk |
but we could fetch the data to make something of it. there is no interaction between users in that scenario |