|author||Jakub Jirutka <email@example.com>||2017-12-15 15:39:36 +0100|
|committer||Jakub Jirutka <firstname.lastname@example.org>||2017-12-15 15:39:36 +0100|
Revert "travis: require check when not explicitly disabled"
This reverts commit da4e9b11fd6a2004c389a90c913ae8fb4f2dff55. After 1.5 months it's quite clear that this was a bad idea. Let me describe a typical situation. Contributor wants to do some small change in abuild. They did it on their system, it works, so they open a PR. And it fails on Travis. Why? Because of missing check(), something totally unrelated to their change! Newbies are often confused. Others know what to do, but adding check() is often non-trivial. Upstream does not provide any tests, tests are broken, extra dependencies are needed, etc. The contributor wanted to do just a small change and now they have to deal with possibly complicated task. That's not okay. And the worst is that it caused some devs to ignore CI results. For example, contributor added php dependency into main/uwsgi. CI failed due to missing check(). Reviewers did not realized that php is in the community repository, not main. And some developer merged it despite CI failed, to revert it few minutes after because it failed on build servers! This is the exact situation that should be prevented by having CI. So, it's a good idea to encourage contributors to add check(), but eagerly failing build on CI is definitely not a good way.
Diffstat (limited to '.travis/build-pkgs')
1 files changed, 1 insertions, 1 deletions
diff --git a/.travis/build-pkgs b/.travis/build-pkgs
index e7d3e59717..3d20f0754c 100755
@@ -79,7 +79,7 @@ for repo in $(changed_repos "$commit_range"); do
fold_start "$pkgname" "Building package $qname"
- if REQUIRE_CHECK=1 abuild -r; then
+ if abuild -r; then
checkapk || :