Hi, I was just wondering that do we really need Travis CI builds for the weblate translation changes as it does not affect test cases.
So why not just ignore builds for those commits and avoid wastage of resources and keep them available for PR?
As weblate changes are so often it is just an overhead on Travis and Scrutinizer causing delays for other PR's and commits unnecessarily.
To skip a build on Travis CI & Scrutinizer CI we can add "[ci skip]" or "[skip ci]" in the commit message (see [1] & [2]). Is it possible to do so?
[1]: http://docs.travis-ci.com/user/how-to-skip-a-build/ [2]: https://scrutinizer-ci.com/docs/guides/skipping_a_build_via_commit_message
-- Regards, Chirayu Chiripal phpMyAdmin Intern - Google Summer of Code 2014 https://chirayuchiripal.wordpress.com/
Hi
Dne Thu, 31 Jul 2014 15:14:39 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
I was just wondering that do we really need Travis CI builds for the weblate translation changes as it does not affect test cases.
Probably not, we do check if po files compile there, but this really does not happen much often now.
So why not just ignore builds for those commits and avoid wastage of resources and keep them available for PR?
As weblate changes are so often it is just an overhead on Travis and Scrutinizer causing delays for other PR's and commits unnecessarily.
To skip a build on Travis CI & Scrutinizer CI we can add "[ci skip]" or "[skip ci]" in the commit message (see [1] & [2]). Is it possible to do so?
I've just added this, thanks for suggestion!
On Thu, Jul 31, 2014 at 5:57 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Thu, 31 Jul 2014 15:14:39 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
I was just wondering that do we really need Travis CI builds for the weblate translation changes as it does not affect test cases.
Probably not, we do check if po files compile there, but this really does not happen much often now.
So why not just ignore builds for those commits and avoid wastage of resources and keep them available for PR?
As weblate changes are so often it is just an overhead on Travis and Scrutinizer causing delays for other PR's and commits unnecessarily.
To skip a build on Travis CI & Scrutinizer CI we can add "[ci skip]" or "[skip ci]" in the commit message (see [1] & [2]). Is it possible to do
so?
I've just added this, thanks for suggestion!
Thanks. This will help in getting results early for PR's in peak hours.
-- Michal Čihař | http://cihar.com | http://phpmyadmin.net
On Thu, Jul 31, 2014 at 6:46 PM, Chirayu Chiripal < chirayu.chiripal@gmail.com> wrote:
On Thu, Jul 31, 2014 at 5:57 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Thu, 31 Jul 2014 15:14:39 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
I was just wondering that do we really need Travis CI builds for the weblate translation changes as it does not affect test cases.
Probably not, we do check if po files compile there, but this really does not happen much often now.
So why not just ignore builds for those commits and avoid wastage of resources and keep them available for PR?
As weblate changes are so often it is just an overhead on Travis and Scrutinizer causing delays for other PR's and commits unnecessarily.
To skip a build on Travis CI & Scrutinizer CI we can add "[ci skip]" or "[skip ci]" in the commit message (see [1] & [2]). Is it possible to do
so?
I've just added this, thanks for suggestion!
Thanks. This will help in getting results early for PR's in peak hours.
It seems like this is having some side effects. Coveralls and Scrutinizer are now not properly working (inspecting) when the latest commit in the master is the translation commit with [CI Skip] and feature branch is on top of that. Or there is something else causing problem with Coveralls and Scrutinizer?
-- Michal Čihař | http://cihar.com | http://phpmyadmin.net
Hi
Dne Wed, 6 Aug 2014 20:06:27 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
It seems like this is having some side effects. Coveralls and Scrutinizer are now not properly working (inspecting) when the latest commit in the master is the translation commit with [CI Skip] and feature branch is on top of that. Or there is something else causing problem with Coveralls and Scrutinizer?
They both get coverage data from Travis and they probably just timeout here.
But at least Scrutinizer should ignore these commits as well:
https://scrutinizer-ci.com/docs/guides/skipping_a_build_via_commit_message
On Tue, Aug 12, 2014 at 1:51 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Wed, 6 Aug 2014 20:06:27 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
It seems like this is having some side effects. Coveralls and Scrutinizer are now not properly working (inspecting) when the latest commit in the master is the translation commit with [CI Skip] and feature branch is on top of that. Or there is something else causing problem with Coveralls
and
Scrutinizer?
They both get coverage data from Travis and they probably just timeout here.
Coveralls is considering such PR's as first build on master (targeted branch), maybe because coveralls sees that latest commit on master is not having coverage report but those changes are in po files only and he should be interested only in libraries/ directory (see [1]).
Scrutinizer cancels inspection due to some mismatch parent commits error (see [2]). I think scrutinizer behavior is kind of a bug.
[1]: https://coveralls.io/builds/1038671 [2]: https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/963075d0-558f...
Hi
Dne Tue, 12 Aug 2014 14:49:53 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
Coveralls is considering such PR's as first build on master (targeted branch), maybe because coveralls sees that latest commit on master is not having coverage report but those changes are in po files only and he should be interested only in libraries/ directory (see [1]).
Indeed this is caused by Coveralls not skipping these commits. Maybe we could use just Scrutinizer as it reports coverage too?
Scrutinizer cancels inspection due to some mismatch parent commits error (see [2]). I think scrutinizer behavior is kind of a bug.
In this case it's IMHO not related - it's just that the pull request has been updated between the build has been scheduled and it has started. These did happen before as well.
On Tue, Aug 12, 2014 at 3:02 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 12 Aug 2014 14:49:53 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
Coveralls is considering such PR's as first build on master (targeted branch), maybe because coveralls sees that latest commit on master is not having coverage report but those changes are in po files only and he
should
be interested only in libraries/ directory (see [1]).
Indeed this is caused by Coveralls not skipping these commits. Maybe we could use just Scrutinizer as it reports coverage too?
Scrutinizer cancels inspection due to some mismatch parent commits error (see [2]). I think scrutinizer behavior is kind of a bug.
[2]:
https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/963075d0-558f...
In this case it's IMHO not related - it's just that the pull request has been updated between the build has been scheduled and it has started. These did happen before as well.
Lets take another inspection [3]. This PR was never updated once it was created and the only inspection was this [3].
[3]: https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/6f395762-0afe...
Hi
Dne Tue, 12 Aug 2014 16:41:43 +0530 Chirayu Chiripal chirayu.chiripal@gmail.com napsal(a):
Lets take another inspection [3]. This PR was never updated once it was created and the only inspection was this [3].
I have no clue here, but I don't see how it could be related to skipping some commits for CI.
-
Chirayu Chiripal -
Michal Čihař