[Phpmyadmin-devel] Skipping Travis CI & Scrutinizer CI builds for weblate pushes
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! -- Michal Čihař | http://cihar.com | http://phpmyadmin.net
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 -- Michal Čihař | http://cihar.com | http://blog.cihar.com
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.
[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. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
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].
[3]: https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/6f395762-0afe...
I have no clue here, but I don't see how it could be related to skipping some commits for CI. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
participants (2)
-
Chirayu Chiripal -
Michal Čihař